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.
Links to research, interviews, designs, competitors, etc.
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.
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
Author accepted manuscript
Version of record
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_article [pubs within journal issue collection],
content_item with type
chapter [pubs within book collection],
conference_paper [pubs within conference collection]. We will need to add support for
peer_review, (as determined by connected objects),
preprint type (as determined by the deposit status field OR connected objects), and
component with type
supplementary_material (as determined by connected objects)
Container title (inherited from the community in case of journal, collection in case of book)
Relationships (from connected objects
…and whatever other stuff we push them that I’ll look up later
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).
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.
Preprints, derived from the status OR from a
isPreprintOf connection, should be
posted_content with type
Supplementary material, derived from a connected object, should be a
component with type
supplementary_material. Note that components are technically children of the parent object (see schema), so we must explicitly notify crossref of the DOI of the parent in the deposit. And, typically, component DOIs mirror the parent DOI, so for components we should disable DOI editing and generate components DOIs accordingly, ie:
10.1111/abcd.123/1 where the parent DOI is
Peer reviews, derived from a connected object, should be type
peer review and should have two further optional options when selected:
HDSR and RR:C19 use it and it works
Other people sign up to pubpub specifically to use this feature
As an author/admin/editor/reader/review … I want …. so I can…
How do people do this now and how does this change that?
They don’t, mostly.
What other parts of the system are impacted?
Who has permissions to do what?
Same permissions as now.
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.