In the first half of this year we’ve been talking to our community about post-publication changes and Crossmark. When a piece of research is published it isn’t the end of the journey—it is read, reused, and sometimes modified. That’s why we run Crossmark, as a way to provide notifications of important changes to research made after publication. Readers can see if the resesarch they are looking at has updates by clicking the Crossmark logo.
We’re happy to note that this month, we are marking five years since Crossref launched its Grant Linking System. The Grant Linking System (GLS) started life as a joint community effort to create ‘grant identifiers’ and support the needs of funders in the scholarly communications infrastructure.
The system includes a funder-designed metadata schema and a unique link for each award which enables connections with millions of research outputs, better reporting on the research and outcomes of funding, and a contribution to open science infrastructure.
In our previous blog post about metadata matching, we discussed what it is and why we need it (tl;dr: to discover more relationships within the scholarly record). Here, we will describe some basic matching-related terminology and the components of a matching process. We will also pose some typical product questions to consider when developing or integrating matching solutions.
Basic terminology Metadata matching is a high-level concept, with many different problems falling into this category.
Update 2024-07-01: This post is based on an interview with Euan Adie, founder and director of Overton._
What is Overton? Overton is a big database of government policy documents, also including sources like intergovernmental organizations, think tanks, and big NGOs and in general anyone who’s trying to influence a government policy maker. What we’re interested in is basically, taking all the good parts of the scholarly record and applying some of that to the policy world.
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)
Description
Reciprocal relationship types
Expression
isExpressionOf, hasExpression
Format
isFormatOf, hasFormat
Identical
isIdenticalTo
Manifestation
isManifestationOf, hasManifestation
Manuscript
isManuscriptOf, hasManuscript
Preprint
isPreprintOf, hasPreprint
Replacement
isReplacedBy, Replaces
Translation
isTranslationOf, hasTranslation
Variant
isVariantFormOf, isOriginalFormOf
Version
isVersionOf, hasVersion
Relationship types for associated research objects: inter-work (between works)
Description
Reciprocal relationship types
Basis
isBasedOn, isBasisFor
Comment
isCommentOn, hasComment
Continuation
isContinuedBy, Continues
Derivation
isDerivedFrom, hasDerivation
Documentation
isDocumentedBy, Documents
Funding
finances, isFinancedBy
Part
isPartOf, hasPart
Peer review
isReviewOf, hasReview
References
references, isReferencedBy
Related material, such as a protocol
isRelatedMaterial, hasRelatedMaterial
Reply
isReplyTo, hasReply
Requirement
requires, isRequiredBy
Software compilation
isCompiledBy, compiles
Supplement, such as a dataset generated as part of research results
isSupplementTo, isSupplementedBy
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.
<journal_article publication_type="full_text">
<titles>
<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>
</titles>
<contributors>
<person_name sequence="first" contributor_role="author">
<given_name>Daniel</given_name>
<surname>Stepputtis</surname>
<ORCID authenticated="true">http://orcid.org/0000-0003-4824-1631</ORCID>
</person_name>
</contributors>
<publication_date media_type="online">
<month>02</month>
<day>28</day>
<year>2013</year>
</publication_date>
<program xmlns="https://www.crossref.org/relations.xsd">
<related_item>
<description>Portuguese translation of an article</description>
<intra_work_relation relationship-type="isTranslationOf" identifier-type="doi">10.5555/original_language</intra_work_relation>
</related_item>
</program>
<doi_data>
<doi>10.5555/translation</doi>
<resource>https://www.crossref.org/</resource>
</doi_data>
</journal_article>
Example: book review
This example has a book review published as an article in the journal The Holocene. The article’s title, taken from the publisher’s site is “Book Review: Understanding the Earth system: compartments, processes and interactions” where this book has the DOI https://doi.org/10.1007/978-3-642-56843-5.
A: The current metadata for the review article gives no indication of the actual book being reviewed:
An article with a Crossref DOI identifies that data represented by a DataCite DOI was used in the research and was mentioned in the article’s acknowledgment section.