Crossref aims to link research together, making related items more findable, increasing transparency, and showing how ideas spread and develop. There are a number of moving parts in this effort: some related to capturing and storing linking information, others to making it available.
By including relationship metadata in Event Data, we are taking a big step to improve the visibility of a large number of links between metadata. We know this is long-promised and we’re pleased that making this valuable metadata available supports a number of important initiatives.
TL:DR; Hi, I’m Joel GitLab UI unsatisfactory Wrote a UI to use the API Wrote a missing API Open company contributes changes back to another open company Now have a method for getting work done much easier Hurrah! I’m Joel, a Senior Site Reliability Engineer here at Crossref. I have a long background in open source, software development, and solving unique problems. One of my earliest computer influences was my father.
Some of you who have submitted content to us during the first two months of 2021 may have experienced content registration delays. We noticed; you did, too.
The time between us receiving XML from members, to the content being registered with us and the DOI resolving to the correct resolution URL, is usually a matter of minutes. Some submissions take longer - for example, book registrations with large reference lists, or very large files from larger publishers can take up to 24 to 48 hours to process.
TL;DR: We have a Community Forum (yay!), you can come and join it here: community.crossref.org.
Community is fundamental to us at Crossref, we wouldn’t be where we are or achieve the great things we do without the involvement of you, our diverse and engaged members and users. Crossref was founded as a collaboration of publishers with the shared goal of making links between research outputs easier, building a foundational infrastructure making research easier to find, cite, link, assess, and re-use.
Typically, when an editorially significant update is made to a document, the publisher will not modify the original document, but will instead issue a separate document (such as a correction or retraction notice) which explains the change. This separate document will have a different DOI from the document that it corrects and will there have different metadata.
In this example, article A (with the DOI 10.5555/12345678) is eventually retracted by a retraction notice RN (with the DOI 10.5555/24242424x). Each document has Crossmark metadata, but the fact that RN updates article A is only recorded in the RN’s Crossmark deposit. The Crossmark internal API has to tie the two documents together and indicate in metadata of the original document (A), that it has been updated_by the second document (RN).
Example 1: simple retraction
This is a simple example of article A being retracted by a retraction notice RN where both A and RN have Crossmark metadata deposited.
First, the PDF is produced and the XML deposited to Crossref.
This is a simple example of article B being corrected by a correction notice CN where both B and CN have Crossmark metadata deposited. The only real difference between this and the previous example is that we are creating a different kind of update.
When a member does not issue a separate update/correction/retraction notice and instead just makes the change to the document (without changing its DOI either), this is called an in-situ update. In-situ updates or corrections are not recommended because they tend to obscure the scholarly record. How do you tell what the differences are between what you downloaded and the update? How do you differentiate them when citing them (remember, we are only talking about “significant updates” here)? However, some members need to support in-situ updates, and this is how they can be supported.
Example 4: correction of article that has no Crossmark metadata deposited
If you deposit Crossmark metadata for a retraction or and update notice which, in turn, points at an article that does not have Crossmark metadata assigned to it, we will generate a “stub” Crossmark for the item being updated. The stub metadata will simply copy essential Crossmark metadata (crossmark_domains and domain_exclusive) from the updating metadata. This metadata can be queried via the Crossref API, but won’t activate anything on your site unless you add the Crossmark widget to the corresponding page of the item being updated.
Example 5: correction notice that corrected multiple documents
Sometimes members issue correction or clarification notices which provide corrections for multiple documents. This too can be supported by Crossmark. In the following example, one correction/clarification document provides updates to two documents (F and G)