Today: January 26, 2017
From the very early days Crossref has supported creating DOIs for components which are parts of an article that needed their own DOI. This allowed members to create DOIs for images, tables, data items or whatever piece of an article should have its own DOI.
With the introduction of relations, which allow for any DOI to be associated with any other DOI by a defined set of relationship types, the old methods for modeling components is showing its age. First, the XML structure for depositing a component captures the component's metadata within the metadata of its parent (typically the journal article). Over the years members have often worked around this constraint to achieve the goal of registering DOIs for non-article level content (e.g. supporting material) by abiding by the XML constraints but abandoning the spirit of the article/component pairing. Second, since in the beginning we had no way to express the pairing of articles and their components we inserted this concept directly into the component's metadata (not really a good idea).
The good news is we're modernizing the treatment for components to address both of these creaky old concepts. The first is the introduction of new genres of content for which DOIs can be assigned. Last year we added preprints and the concept of early DOI registration and this year we're already talking about other new content genres (stay tuned). This 'opening up' of our content type genres will greatly ease the decision of how component DOIs may be deposited and do away with the mandatory (and often artificial) embedding imposed by the XML structure. Don't worry the current deposit model for components will not be going away anytime soon.
Second we're about to convert all existing components and newly deposited components to use the new relations metadata constructs. When complete the pairing between a component and its parent article(s) will be declared in the <crm-item> tag in the section of XML where we insert Crossref generated metadata for a DOI. This section separates member supplied metadata from auto generated metadata, a really good idea. This change will impact any XML metadata consumers who are looking for the article/component pairing relationships in the metadata. Essentially we're just moving it. Also, since Crossref's REST-API will soon reflect relationship data, our converting article/component pairings to use relations results in all relationship data appearing in a uniform manner.
This change will not impact deposits at all. Members can continue with their existing work flows. DOI metadata viewed using the UNIXSD format will change.
Instead of this:
<parent_doi last_update_date="2016-12-01" parent_relation="IsPartOf">
You'll see this:
<crm-item name="relation" type="doi" claim="hasComponent">
See the Crossref help documentation for a fuller description of DOI relations.
We expect the impact to be fairly small and would like to introduce this change in the next two to three weeks. For more information or to express any concerns please contact email@example.com.