Skip to main content

Spec: DOI Deposit Refactor (for Pub Connections)

Published onJul 16, 2020
Spec: DOI Deposit Refactor (for Pub Connections)


What is it, who’s it for, what is the core need of those people that this addresses, and how does it address their needs in a way that improved upon competitors and our current feature-set?

This is a minor overhaul of the DOI deposit section of the settings page with really 4 core features: It allows users to change the crossmark status of a deposit, allows users to customize the DOI to be displayed on the article in case it was generated in another system, adds a preview of how Pubs will be deposited, and, behind the scenes, adds handling for depositing connected Pubs and crossmark statuses in Crossref.

Eventually, we should add the ability to submit to crossref with some limited options as part of the Release flow — so these components should be relatively reusable. But that’s out of scope for this spec.

Supporting Links/Research

Links to research, interviews, designs, competitors, etc.

What is it?

List all of the main features, hopefully in rough priority order. Typically these are broken down into descriptions of screens/interface components and their purpose.

  1. Deposit status — adds a field to support different crossmark statuses (can be deposited with main pub deposit, see schema). For now, we should support:

    • Preprint

      • once deposited with this status, it cannot be changed, and should also update the type of submission to be posted_content with a type of preprint

    • Pending publication

    • Author accepted manuscript

    • Version of record

  2. Deposit preview — we should always show a preview of how we will deposit the article in crossref and, in cases where we’re pulling data from the collection or a connection, an indication of how we’re deriving those fields. If a user has never deposited the Pub, we should indicate it will be a new deposit. If it’s an update, we should warn that it’s already been deposited and this will cause any changed fields to update. Ideally we’d store fields from last deposit and be able to detect and show changes since, but that’s not really mandatory. The preview should include:

    • The DOI itself [autogenerated or manually entered]

    • The type of deposit, inherited from either the primary collection OR the first type-dependent pub object connection OR the status field, with status taking precedence, followed by the first pub object connection, followed by the collection. We already support journal_issue [collection], journal_article [pubs within journal issue collection], book [collection], content_item with type chapter [pubs within book collection], conference [collection], conference_paper [pubs within conference collection]. We will need to add support for peer_review, (as determined by connected objects), posted_content with preprint type (as determined by the deposit status field OR connected objects), and component with type supplementary_material (as determined by connected objects)

    • Title

    • Container title (inherited from the community in case of journal, collection in case of book)

    • Authors

    • Abstract

    • Date published

    • License

    • Relationships (from connected objects

    • …and whatever other stuff we push them that I’ll look up later

  3. Editable DOI field — If a user has not submitted a DOI yet, the DOI field (everything after the 10.1111/ prefix) should be editable, and validated against the approved characters. Sometimes, users generate a DOI in another system and need to be able to use it when they deposit the pub. Sometimes, users manage DOI depositing in another system entirely and just want to update this field in the database. The DOI field should be changeable and save to the DB up until a user makes a first deposit. At that point, it should no longer be editable. On the first submission of a DOI, we should warn users that once they submit, they will no longer be able to change the DOI (in reality, we could do this in the db if we really needed to, but for the most part we should avoid changing doi after deposit).

  4. Support for depositing crossref relationships and types inherited from collections and connected objects — if a pub has a connected object(s), we need to deposit the pub to crossref with the correct relationships and, in some cases, a different type. Because of the bidirectional nature of crossref relationship types, we should support adding the relationship from both ends of a connected object edge – but only when the edge itself is deposited. In other words, if a pub that is a child peer review of another pub is published, we should only register the child Pub’s “isReviewOf” relationship, not the parent Pub’s “isReviewedBy” relationship. But if someone deposits the parent Pub later, and they have “accepted” the review by turning it on, we should deposit it with the isReviewedBy relationship (displaying that we’re doing it in the preview, of course). Mostly, we can continue to inherit the type of the deposit from the collection – that is, Pubs in journal collections should be journal_articles, Pubs in book collections should be book_chapters, with a few exceptions. To calculate these exceptions, we should look first at the status, for preprints, then for the first matching connections. That is, if a Pub has two connections listed in the order 1. supplement, 2. peer review, the type will be supplement unless the user re-orders it to make the peer review come first.

What is success?

  1. HDSR and RR:C19 use it and it works

  2. Other people sign up to pubpub specifically to use this feature

Design Process

Feature 1



  1. As an author/admin/editor/reader/review … I want …. so I can…


Implementation Checklists

  • How do people do this now and how does this change that?

    • They don’t, mostly.

  • What other parts of the system are impacted?

    • Crossref submission.

  • Who has permissions to do what?

    • Same permissions as now.

  • Mobile support?

    • Meh

  • Active states?

    • Meh

  • Error states?

    • We should update the submission page with a notice that we can’t guarantee crossref submission, and that they should check back in 12-24 hours before asking us for help if a DOI is not registered.

Tech Implementation Checklist

  • Performance


No comments here
Why not start the discussion?