In August 2022, the United States Office of Science and Technology Policy (OSTP) issued a memo (PDF) on ensuring free, immediate, and equitable access to federally funded research (a.k.a. the “Nelson memo”). Crossref is particularly interested in and relevant for the areas of this guidance that cover metadata and persistent identifiers—and the infrastructure and services that make them useful.
Funding bodies worldwide are increasingly involved in research infrastructure for dissemination and discovery.
Preprints have become an important tool for rapidly communicating and iterating on research outputs. There is now a range of preprint servers, some subject-specific, some based on a particular geographical area, and others linked to publishers or individual journals in addition to generalist platforms. In 2016 the Crossref schema started to support preprints and since then the number of metadata records has grown to around 16,000 new preprint DOIs per month.
TL;DR One of the things that makes me glad to work at Crossref is the principles to which we hold ourselves, and the most public and measurable of those must be the Principles of Open Scholarly Infrastructure, or POSI, for short. These ambitions lay out how we want to operate - to be open in our governance, in our membership and also in our source code and data. And it’s that openness of source code that’s the reason for my post today - on 26th September 2022, our first collaboration with the JSON Forms open-source project was released into the wild.
Ans: metadata and services are all underpinned by POSI.
Leading into a blog post with a question always makes my brain jump ahead to answer that question with the simplest answer possible. I was a nightmare English Literature student. ‘Was Macbeth purely a villain?’ ‘No’. *leaves exam*
Just like not giving one-word answers to exam questions, playing our role in the integrity of the scholarly record and helping our members enhance theirs takes thought, explanation, transparency, and work.
We maintain an expansive set of relationship types to support the various content items that a research object, like a journal article, might link to. For data and software, we ask you to provide the following information:
identifier of the dataset/software
identifier type: DOI, Accession, PURL, ARK, URI, Other (additional identifier types are also accepted beyond those used for data or software, including ARXIV, ECLI, Handle, ISSN, ISBN, PMID, PMCID, and UUID)
relationship type: isSupplementedBy or references (use the former if it was generated as part of the research results)
description of dataset or software
We and DataCite both use this kind of linking. Data repositories which register their content with DataCite follow the same process and apply the same metadata tags. This means that we achieve direct data interoperability with links in the reverse direction (data and software repositories to journal articles).
The possible relationship types between content items can be as varied as the items themselves. We use a controlled vocabulary to define these relationships, in order to construct an orderly mapped network of content.
This is achieved by (i) an implicit approach where the relation type is a function of a specific service and is declared in the structure of the deposited XML, and (ii) in an explicit approach where the relation type is selected as a value within the deposited metadata.
Reference linking and Cited-by: implicitly creates cites and isCitedBy relationships between a content item and the items in its bibliography
Crossmark: explicit creation of update relations between an item and other items that materially affect it (for example, a retraction)
Funding data: implicit creation of isFundedBy and hasAward relationships between an item and the funding source that supported the underlying research
Linked clinical trials: implicit creation of a belongsTo relationship between and item and a registered clinical trial
Components: implicit creation of a isChildOf relationship between an item and its elemental parts that are assigned their own DOI (limited parent relation typing)
General typed relations: explicitly typed relation between an item with a Crossref DOI and an item with one of several possible identifiers.
Relationship types for associated research objects: intra-work (within a work)
Reciprocal relationship types
Relationship types for associated research objects: inter-work (between works)
Reciprocal relationship types
Related material, such as a protocol
Supplement, such as a dataset generated as part of research results
General typed relations
This service allows for the creation of a typed relationship between an item with a Crossref DOI and another content item. The other item may be represented by another Crossref DOI, a DOI from some other Registration Agency, or an item not identified with a DOI. When DOIs are used, the deposit process will fail if the DOI does not exist. Non-DOI identifiers are not verified.
When DOIs are used, a bidirectional relation is automatically created by us when a relation is created in the deposit of one item in a pair. The DOI with metadata creating the relation is said to be the claimant, the other item does not need to have its metadata directly contain the relationship.
Example: translated article
A single journal article is published in two languages with each being assigned its own DOI. In this example, both are published in the same journal. The original language instance has metadata that contains no indication of the translation instance. The alternative language instance includes in its metadata a relation to the original language instance. Here is a screenshot of the relevant section in the code. Please refer to the code snippet below to see it in context.
<title>Um artigo na língua original, que passa a ser o inglês</title>
<original_language_title language="en">An article in its original language which happens to be English</original_language_title>
<person_name sequence="first" contributor_role="author">
<description>Portuguese translation of an article</description>
<intra_work_relation relationship-type="isTranslationOf" identifier-type="doi">10.5555/original_language</intra_work_relation>