Learn more on Crossref

Author / article title query

Mon, 01 Jan 0001 00:00:00 +0000

Author / article-title query

The Crossref system now supports a query mode where only article title and/or first author surname are required. These queries can be performed using an XML query.

Example: XML author / article-title query

... <query enable-multiple-hits="false" secondary-query="author-title" key="key1"> <article_title match="fuzzy">Concluding remarks</article_title> <author search-all-authors="true">Somiari</author> </query> <query enable-multiple-hits="false" secondary-query="author-title" key="key1"> <article_title match="fuzzy">Off-line Approaches</article_title> <author search-all-authors="true">Gustafsson</author> </query> ...

When performing a bulk upload using HTTP POST, the value of the HTTP parameter ‘operation’ must be doQueryUpload (please see Using HTTP to POST files).

This service by default returns only one DOI record per query. As with other metadata queries if the system finds more than one possible DOI the results are considered ambiguous and thus no results are returned. The user may override the one result rule and request that multiple hits may be returned.
When performing XML queries, an author-title query may be submitted as a secondary query if the initial full metadata query is unsuccessful.
Only the <author> and <article_title> elements should appear in an author / article title query - if other elements are present, the query will be performed as a full metadata query.

Best practice for maintaining DOIs

Mon, 01 Jan 0001 00:00:00 +0000

Best practice for maintaining Crossref DOIs

Displaying Crossref DOIs

Follow Crossref DOI Display guidelines.
DOIs, along with volume, issue and page numbers, should be part of the standard bibliographic metadata for an article
DOIs should be displayed in bibliographic headers for online AND print articles
The DOI should be an active link
Include information about using DOIs in your instructions for authors. For an example, see the information Nature provides for authors about Advanced Online Publication.

Maintaining DOI and metadata {style=“line-height: 19px; “}

Update URLs when needed
Review reports regularly to identify issues
redeposit DOIs with new metadata options (ORCID, funding) whenever possible.

Best practice for querying

Mon, 01 Jan 0001 00:00:00 +0000

Best practice for querying

Journal Titles & ISSN - One of the most powerful features of the Crossref system is its fuzzy matching processes. Consequently we strongly encourage the use of journal title as an identifier instead of ISSN. Queries that supply only ISSN tend not to resolve as well as those that supply just journal title or both title and ISSN. ISSN is essentially treated as a number resulting in the need to perform an exact match on the text string representation. Very little normalization can be done. Title however is a very complex value that can be normalized in several ways giving the matching function more options as it seeks to locate the proper DOI.

Use XML - XML is the preferred format to use when sending queries into the Crossref system. This format is more precise, offers more functionality and is extensible. All new query features will only be offered through the XML format. Support of the legacy pipe’d format will continue but it will not be extended. See Querying with XML.

Include complete metadata - include all available metadata in your query whenever possible.

Bulk metadata formats

Mon, 01 Jan 0001 00:00:00 +0000

Bulk metadata formats

Crossref will distribute the entire metadata repository to CMS subscribers. The data is made available using two transaction models. Each model produces a slightly different format of data.

FTP/HTTP of ZIP Archives

In this model Crossref produces an XML file for each title containing all DOIs for that publication. The files are built to the Crossref output schema (schema | documentation).

Crossref runs daily and weekly processes that create files containing new or updated DOIs during these periods. The files are then combined into a compressed archive (Zip’d Unix tar files). The archives are stored in a set of 7 daily folders, named day0 through day6, and 4 weekly folders, named week0 through week3. After 7 days the daily runs reuse the folders overwriting the older daily data while after 4 weeks the weekly run overwrites the oldest weekly data. A control file is used to indicate to which folders the most recent runs wrote their data. In addition, once a month a ‘full’ run is made that produces a file for each title that contains all DOIs, regardless of when they were deposited or last updated.

In the XML <publication> element the attribute ‘filedate’ defines the date when this data was created and the attribute ‘mode’ defines the production mode as daily,weekly or full. On each <doi_element> record the attribute ‘citationid’ is an internal database key used for the DOI and ‘datestamp’ is the date when the DOI was deposited or last updated (useful in weekly or full mode)

CMS Basic for additional information and sample data

OAI-PMH

OAI-PMH is a protocol for metadata harvesting and a full description is available at www.openarchives.org. To summarize, this protocol defines a set of HTTP requests that allow a harvester to interact with a repository to pull selective metadata or all available data. Normally, an OAI-PMH compatible repository provides free and open access to its data. Crossref however has implemented an access control mechanism based on recipients and their IP address. Each recipient must be registered with Crossref. Crossref member publishers may choose to opt-out for a given recipient. The publishers may also choose to opt-out/opt-in on a title by title basis, making a subset of their metadata available to the specific recipient.

By default all members are set as opt-in, including all titles. When Crossref is made aware that a new recipient intends to subscribe to the PMH service a window of time will be allowed for members to decide to opt-out, if they take no action the default opt-in settings will be applied.

Dublin Core (DC) is the standard format for metadata distribution by a PMH compliant repository. However, DC is not expressive enough to represent the full metadata available in Crossref. While DC is not currently support by Crossref’s PMH interface we will likely add support in the near future to achieve compatibility with the specification. Our PMH currently generates data formatted using our Unified XML schema (schema | documentation).

Each record retrieved through the PMH interface will have the complete metadata as deposited by the publisher for that DOI. Crossref’s repository supports a two level hierarchical set organization. At the top level are the publisher sets where the set identifier is the DOI prefix for the publisher. The next level is the publication title level where the set identifier is an internal value assigned by Crossref for the publication.

All PMH identifiers are DOIs expressed using the IETF RFC 4452 “The ‘info’ URI Scheme for Information Assets with Identifiers in Public Namespaces” (see the info-uri registry).

CMS Enhanced for additional information and sample data

Crossref Affiliates

Mon, 01 Jan 0001 00:00:00 +0000

Crossref Affilates

Crossref’s Affiliate programs are for organizations that are not primary publishers but want to retrieve Crossref DOIs and bibliographic metadata for persistent linking to publisher full text. A range of affiliate programs are available. More information is available on the Crossref website.

Transferring titles

Patricia — Tue, 17 Jan 2017 00:00:00 +0000

We enforce the concept of ownership for the content you register through us. If you ‘own’ a title, you are the member with permissions and responsibilities for creating metadata for that title. We control ownership using the DOI prefix. A single DOI prefix may be applied to a single title, a single publisher, or to a number of publishers (via a sponsoring publisher arrangement). This means that a member with prefix 10.1234 is the only member allowed to create identifiers for a title owned by that prefix. If a title is acquired by a member with prefix 10.5678, we can move the title ownership to prefix 10.5678.

Title ownership may change if:

a title is acquired by a different publisher
there is a change in publishing partner
there is a change in hosting platform

Title vs. DOI ownership

Ownership may be applied to titles and/or to individual records. Typically when a title is acquired by a publisher, existing content is also acquired. We move ownership of the existing records as well as the title to the acquiring publisher. This allows the acquiring member to update existing records registered with the previous owner’s prefix. This ownership change does not change the actual prefix of the DOI, it only affects permissions associated with updating the metadata and URLs. If the DOI 10.1234/5678 is acquired by a member and assigned to prefix 10.5678, then the DOI will continue to be 10.1234/5678 but the member responsible for prefix 10.5678 is able to update the metadata record for 10.1234/5678.

We can also assign ownership to individual records within a title. This is often necessary when content ownership or hosting responsibility is assigned to different chunks of content. For example, current issues of Journal A may be published by a member with prefix 10.1234. Issues of Journal A published prior to 2010 are hosted and maintained by a member with prefix 10.5678. Journal A is owned by prefix 10.1234, but the member with prefix 10.5678 retains control of the back issue DOIs owned by prefix 10.5678.

Establishing and transferring ownership

We allow members to freely register records for titles that do not exist in our system. When the first content registration submission is processed, a title record is added to our database and ownership is assigned to the submitting prefix. If the ownership of a title changes, we’ll need to intervene to allow the new owner to assume responsibility for the title.

Here are the basic steps involved in transferring ownership:

You must notify us of the transfer - if a title transfer has been posted to the Enhanced Transfer Alerting Service (ETAS), let us know and we’ll proceed with the transfer without further confirmation. Members who do not participate in Transfer must send support@crossref.org confirmation that the disposing publisher is aware of and agrees with the ownership transfer. The confirmation may be a forwarded email from the disposing publisher to the acquiring publisher acknowledging the transfer. Please be specific about what is being transferred - include ISSNs, ISBNs, and when you need the transfer to occur (if applicable).
Once we’ve confirmed the transfer, we’ll update the ownership of your title in our system.
At this point you’ll be able to update existing metadata records and create new ones. If the metadata supplied by the previous publisher is complete and accurate you’ll only need to supply us with new URLs to direct records to your content.

Dispute resolution

Title ownership may come into dispute when an organization is not legally recognized as the publication owner and is registering content under agreement with the publication owner. In all cases we’ll abide by the publication owner’s directions concerning the disposition of the DOI names associated with their titles. If the publication owner enacts a transfer that negatively impacts another organization, the organization must find remediation with the publication owner.

DOI ownership may also come into dispute when two members claim ownership of a single publication. As described above, the ‘owning’ member is the first depositor and acquires the ability to continue depositing DOI names for that title. The ‘disputing’ member is denied the ability to deposit and initiates the following resolution process:

The disputing member will notify us of the problem - an email to support@crossref.org is sufficient.
We’ll contact the owning member informing them of the problem
If the owning member agrees that their ownership is incorrect or does not respond with 5 business days Crossref will assign title and record ownership to the disputing member.
If the owning member challenges the claim, we’ll request that the two parties resolve the issue and submit joint instructions on how to disposition ownership.
If joint resolution is not achieved within 30 days Crossref will suspend the owning member’s ability to deposit new DOI names for the publication.
If joint resolution is not achieved within 60 days Crossref will modify the appropriate DOI names to a landing page indicating that ownership is in dispute.

At any time during joint resolution deliberation Crossref will accept direction from legal authority specifying how to establish owners

1. Permissions

Mon, 01 Jan 0001 00:00:00 +0000

Authorizing Multiple Resolution deposits

Multiple resolution typically involves two (or more) publishers involved in a co-hosting agreement. For the purposes of multiple resolution, the *primary depositor* is the content owner, meaning they represent the organization that holds copyright for the content or is otherwise known as the publisher. Multiple resolution DOIs are owned by the primary depositor’s prefix. The *secondary depositor* co-hosts content with the primary depositor - they have been authorized by the content owner to serve the content on-line and assign additional URL to DOIs. Crossref will always defer to the primary depositor’s instructions regarding changes to DOI metadata including all assigned URLs.

Permissions

Before depositing, the primary or secondary depositor must notify Crossref of the intention to deposit multiple resolution DOIs, and all titles and prefixes involved. The secondary depositor may coordinate multiple resolution activity with Crossref with permission from the primary depositor - this can be an email to support@crossref.org stating “XYZ Publishing has permission to coordinate multiple resolution activity on our behalf for titles (…)”

Enabling a deposit account for multiple resolution

The Multiple Resolution process only permits URL data to be deposited by secondary depositors - other metadata can only be deposited and updated by the primary depositor. The primary depositor will be able to perform all multiple resolution functions using their current Crossref system account. The secondary depositor will be assigned a new system account to be used for multiple resolution deposits only.

Creating an interim page template, Enable DOIs for Multiple Resolution, Deposit Secondary URLs

2. Interim page template

Mon, 01 Jan 0001 00:00:00 +0000

Building the interim page template

The interim page is displayed based on an HTML template. The template operates on a simple text replacement process. The current interim page function currently supports directives which can appear anywhere in the template HTML file:

<!–doi–> will be replaced by the DOI
<!–metadata–> will be replaced by metadata associated with the DOI as HTML table rows and data cells
<!–link–> will be replaced by URL of one MR target (multiple uses of this directive will iterate through the available MR secondary targets)
<!–link-prime–> will be replaced by the primary URL (presumably the content owner’s URL)
<!–link label=“XYZ123”–> will be replaced by the URL of the MR target deposited with the specified label. Labels used in *<!–link label=“XYZ123”–>* must match the label supplied in deposits by the secondary depositor.

HTML template download sample or + show/hide example

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>Current Links for doi:</title>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<link rel="stylesheet" rev="stylesheet" type="text/css" href="/iPage/docs/css/mr.css" />

</head>

<body leftmargin="10" topmargin="10" bgcolor="#CCCC99">

<table width="650" cellpadding="10" bgcolor="#FFFFFF" border="0">

<tr><td><img src="/iPage/docs/images/Graft_cover.gif" alt="Graft" align="left" /></td>

<td><i>Graft: Organ and Cell Transplantation</i> is no longer in publication. Online access to this title is now provided through the archiving organizations listed below.</td>

<td> </td>

</tr>

</table>

<table width="650" cellpadding="10" bgcolor="#FFFFFF" border="0">

<tr>

<td colspan="4">

<hr />

<table width="450">

</table>

<hr />

</td>

</tr>

<span class="article">

<tr>

<td align="center" valign="bottom" width="200">

<a href=>| Article Available - Portico |</a>

</td>

<td align="center" valign="bottom" width="200">

<a href=>| Free Article - EDINA |</a>

<br /><br />

<a href=>| Free Article - Stanford University |</a>

</td>

<td align="center" valign="bottom">

<a href=>| Article Available - Koninklijke Bibliotheek|</a>

</td>

</tr>

</span>

<tr>

<td align="center" valign="top" ><a href="http://www.portico.org"><img src="/iPage/docs/images/portico.gif" align="top" alt="Portico Logo" border="0"></a><br /><br /></td>

<td align="center" valign="top" ><a href="http://www.clockss.org"><img src="/iPage/docs/images/CLOCKSS.gif" align="top" alt="CLOCKSS logo" border="0"></a><br /><br /></td>

<td align="center" valign="top" ><img src="/iPage/docs/images/KB.gif" align="top" alt="KB Logo" border="0"><br /><br /></td>

</tr>

<tr>

<td colspan="4"><hr /></td>

</tr>

</table>

</body>

</html>

Example HTML (populated with MR data) + show/hide example

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>Current Links for doi:10.1177/152216280100400206</title>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<link rel="stylesheet" rev="stylesheet" type="text/css" href="/iPage/docs/css/mr.css" />

</head>

<body leftmargin="10" topmargin="10" bgcolor="#CCCC99"><table width="650" cellpadding="10" bgcolor="#FFFFFF" border="0">

<tr>

<td><img src="/iPage/docs/images/Graft_cover.gif" alt="Graft" align="left" /></td>

<td><i>Graft: Organ and Cell Transplantation</i> is no longer in publication. Online access to this title is now provided through the archiving organizations listed below. </td>

<td> </td>

</tr>

</table>

<table width="650" cellpadding="10" bgcolor="#FFFFFF" border="0">

<tr>

<td colspan="4"><hr />

<table width="450">

<tr>

<td><b>Determining Significant Physiologic Incompatibilities</b></td>

</tr>

<tr>

<td>Claus Hammer</td></tr><tr><td></td></tr><tr><td><i>Graft</i> (2001), 4(2):108</td>

</tr>

<tr>

<td><a href='http://dx.doi.org/10.1177/152216280100400206'>http://dx.doi.org/10.1177/152216280100400206</td>

</tr>

</table>

<hr />

</td>

</tr>

<span class="article"><tr>

<td align="center" valign="bottom" width="200"><a href=http://www.portico.org/Portico/article?article=pd3qzhfgp>| Article Available - Portico |</a></td>

<td align="center" valign="bottom" width="200"><a href=http://triggered.edina.clockss.org/ServeContent?rft_id=info:doi/10.1177/152216280100400206>| Free Article - EDINA |</a>

<br /><br /><a href=http://triggered.stanford.clockss.org/ServeContent?rft_id=info:doi/10.1177/152216280100400206>| Free Article - Stanford University |</a> </td>

<td align="center" valign="bottom"><a href=http://sru.kb.nl/sru/sru.pl?query=%2210.1177/152216280100400206%22&recordSchema=dcx&stylesheet=/sru/stylesheets/bladeren/bladeren.xsl&maximumRecords=1&startRecord=1&sortKeys=title&x-collection=eDepot>| Article Available - Koninklijke Bibliotheek|</a></td>

</tr>

</span>

<tr>

<td align="center" valign="top" ><a href="http://www.portico.org"><img src="/iPage/docs/images/portico.gif" align="top" alt="Portico Logo" border="0"></a>

<br /><br /></td>

<td align="center" valign="top" ><a href="http://www.clockss.org"><img src="/iPage/docs/images/CLOCKSS.gif" align="top" alt="CLOCKSS logo" border="0"></a><br /><br /></td>

<td align="center" valign="top" ><img src="/iPage/docs/images/KB.gif" align="top" alt="KB Logo" border="0"><br /><br /></td>

</tr>

<tr><td colspan="4"><hr /></td>

</tr>

</table>

</body>

</html>

Example interim page: http://dx.doi.org/10.1177/152216280100400206

Images and stylesheets may be provided along with the template as needed.
Multiple resolution DOIs deposited without an associated template will default to a generic Crossref template (not recommended)
The directive <!–items–> will be replaced by all links to all MR targets as a HTML table rows and data cells (one link per row). This directive is part of the system template but is not recommended as the result is ugly.

Establishing Multiple Resolution permissions, Enable DOIs for Multiple Resolution, Deposit Secondary URLs

3. Enable DOIs

Mon, 01 Jan 0001 00:00:00 +0000

Enable DOIs for Multiple Resolution

The primary depositor must enable (or ‘unlock’) each multiple resolution DOI before secondary URLs can be deposited. This can be done using either a metadata deposit or a resource deposit. It is expected that once a content owner gives permission for multiple resolution to be attached to DOIs of a given title, or to all their content, that the content owner will routinely enable multiple resolution when creating/updating their DOIs.

Unlock DOIs using the main deposit schema

This mode should be used for all new DOIs created after the content owner has recognized that secondary deposits will be taking place. It allows the primary content owner to enable the DOI MR permission at the same time the DOI is initially created.

The XML used by the content owner to create (or update) the DOI must include an a <collection> element with the multi-resolution attribute set to ‘unlock’.

<?xml version="1.0" encoding="UTF-8"?> <doi_batch version="4.3.0" xmlns="http://www.crossref.org/schema/4.3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/schema/4.3.0 http://www.crossref.org/schemas/crossref4.3.0.xsd"> <head> <doi_batch_id>123456</doi_batch_id> <timestamp>19990628123304</timestamp> <depositor> <name>xyz</name> <email_address>support@crossref.org</email_address> </depositor> <registrant>Crossref Test</registrant> </head> <body> <journal> <journal_metadata language="en"> <full_title>Sample Journal</full_title> <abbrev_title>SJ</abbrev_title> <issn media_type="print">55555555</issn> </journal_metadata> <journal_issue> <publication_date media_type="print"> <year>2008</year> </publication_date> <journal_volume> <volume>10</volume> </journal_volume> <issue>10</issue> </journal_issue> <journal_article publication_type="full_text"> <titles> <title>Sample Article</title> </titles> <contributors> <person_name sequence="first" contributor_role="author"> <given_name>Firstname</given_name> <surname>Surname</surname> </person_name> </contributors> <publication_date media_type="print"> <year>2008</year> </publication_date> <pages> <first_page>1</first_page> </pages> <doi_data> <doi>10.50505/mrtest</doi> <resource>http://www.crossref.org/help/</resource> <collection property="list-based" multi-resolution="unlock" /> </doi_data> </journal_article> </journal> </body> </doi_batch>

Unlock DOIs using the DOI resources schema

This approach can be used for all pre-existing DOIs or can be used for new DOIs if the content owner does not wish to include this metadata in their main DOI deposit. Resource-only deposits should be uploaded as ‘DOI Resources’ when using the system interface or ‘operation=doDOICitUpload’ when doing a programmed HTTP transaction.

<?xml version="1.0" encoding="UTF-8"?> <doi_batch version="4.3.0" xmlns="http://www.crossref.org/doi_resources_schema/4.3.0"> <head> <doi_batch_id>123456</doi_batch_id> <depositor> <name>xyz</name> <email_address>support@crossref.org</email_address> </depositor> </head> <body> <doi_resources> <doi>10.50505/mrtest</doi> <collection property="list-based" multi-resolution="unlock" /> </doi_resources> <doi_resources> <doi>10.50505/mrtest2</doi> <collection property="list-based" multi-resolution="unlock" /> </doi_resources> <doi_resources> <doi>10.50505/mrtest3</doi> <collection property="list-based" multi-resolution="unlock" /> </doi_resources> </body> </doi_batch>

Establishing Multiple Resolution permissions, Creating an interim page template, Deposit Secondary URLs

Accepting a conflict as is

Mon, 01 Jan 0001 00:00:00 +0000

Accepting a conflict as is

In some cases, you may want to leave conflicting or ambiguous records in the Crossref metadata database. For example, you might receive the following message that indicates that four DOIs are involved in seven related conflicts:

Created: 2005-07-28 00:48:53.0
ConfID: 118504
CauseID: 81049593
OtherID:
JT: Journal of the American Chemical Society
MD: null, 126 ,30,9465,2004,null
DOI: 10.1021/ja040932t (118502-null 118503-null 118504-null 118624-null 118625-null 118626-null 118627-null )
DOI: 10.1021/ja040944e (118502-null 118503-null 118504-null 118624-null 118625-null 118626-null 118627-null )
DOI: 10.1021/ja040943m (118503-null 118504-null 118624-null 118625-null 118626-null 118627-null )
DOI: 10.1021/ja0409311 (118504-null 118624-null 118625-null 118626-null 118627-null )

By viewing the Conflict report, you know that all four DOIs point to the same page in the same issue and that none have an author or article_title element.

When you look at each DOI involved in the conflict, you see that all four DOIs point to Book Reviews on the same page of the same issue. You also determine that there simply is not enough metadata to distinguish the four DOIs from each other.

In this case, you should accept these conflicts as-is manually using the system interface or by uploading a .txt file. The Crossref system will then return results such as the following:

In another case, you might upload partial metadata for several DOIs prior to publication, knowing that they will be in temporary conflict until you can update them with page numbers. Again, you should accept the conflicts, which will disappear when you supply the additional information.

If a conflict has been previously resolved using primary/alias or forced alias, attempting to ‘resolve’ the conflict using these methods will undo any aliased pairings established in Handle.

Accepting a conflict as-is using the Crossref System interface

To accept conflicts:

Access the Crossref system.
Click the Metadata Admin tab.
Click the Conflict tab, if necessary.
Enter either the submission ID, the conflict ID, or the DOI ID in the appropriate box.
Select Show Consolidated Conflicts, if available.
Click Submit to see the DOIs associated with the conflict.
Click Mark All Conflicts as Resolved.

If you make a mistake, you can undo it by returning to this page and clicking ‘Unresolve All Conflicts’.

Accepting a conflict as-is by uploading conflict management submissions to the Crossref System

If you have a large number of DOIs to resolve, you can submit a text file to the Crossref system.

Create a .txt file with op=resolve
H:email=youremailaddress;op=resolve
10.1016/0032-1028(80)90001-2
10.1016/0032-1028(80)90002-4
10.1016/0032-1028(80)90003-6
10.1016/0032-1028(80)90004-8
10.1016/0032-1028(80)90005-X
10.1016/0032-1028(80)90006-1
10.1016/0368-3281(63)90014-7
Access the Crossref system.
Click the Submissions tab.
Click the Upload tab, if necessary.
Locate and select the metadata file.
Select Live.
Select Conflict Management.
Click Upload.

Double-checking that conflicts were resolved

To double-check that any conflict associated with a DOI was eliminated:

Access the Crossref system.
Click the Metadata Admin tab.
Click the Conflict tab, if necessary.
Enter the DOI ID in the appropriate box.
Clear all the options.
Click Submit to see whether any conflict still exists.

Accessing the Crossref system

Mon, 01 Jan 0001 00:00:00 +0000

Accessing the Crossref system

The Crossref system’s public interface can be accessed at https://doi.crossref.org. This interface can be used to:

The Crossref system is undergoing redevelopment. As a result, query reports are not available.

Allowing multiple hits

Mon, 01 Jan 0001 00:00:00 +0000

Allowing multiple hits

The Crossref query engine operates by processing many different rules in series. Normally if the output of any rule is a single DOI, processing terminates and that DOI is returned as the result of the query. If no rule can produce only one DOI the query fail results (its results are an ambiguous set). This behaviour is necessary because most processes querying Crossref are automated and are incapable of deciding what to do with multiple DOI records.

However, in an editorial environment where a person is involved, getting multiple results may be valuable if the system is unable to reduce the match to a single item.

To enable the Crossref system to return more than result, set the enable-multiple-hits attribute for query to “true”, ”exact” or “multi_hit_per_rule” for a given query item.

To retrieve a candidate list of DOIs use the enable-multiple-hits attribute:

<query key=“key” enable-multiple-hits=“true/false/multi_hit_per_rule/exact”>

Each option invokes the following responses:

True: Instructs the query function to return the single DOI produced by all the various rules. The output of a rule that produces more than one DOI will not be included.

MULTI_HIT_PER_RULE: Instructs the query engine to return all DOIs uncovered by each rule.

Exact: Disables the normal rule processing and instructs the query engine to perform a simple comparison to the query values and return all DOIs that match (up to a limit of 40).

As-crawled CSV upload

Mon, 01 Jan 0001 00:00:00 +0000

Adding as-crawled URLs for CrossCheck indexing using a .csv file

As-crawled URLs may now be added to an existing DOI using the web deposit form. DOIs and URLs to be used for CrossCheck indexing must be submitted in .csv format. The file should contain two columns with the headings ‘DOI’ and ‘<item crawler=“iParadigms”>’ where DOI is the DOI being updated and *<item crawler=“iParadigms”>*is the URL being submitted for CrossCheck indexing. For example (right-click to download):

DOI,<item crawler="iParadigms">
10.5555/test1,http://www.crossref.org/test1
10.5555/test2,http://www.crossref.org/test2
10.5555/test3,http://www.crossref.org/test3
10.5555/test4,http://www.crossref.org/test4
10.5555/test5,http://www.crossref.org/test5
10.5555/test6,http://www.crossref.org/test6
10.5555/test7,http://www.crossref.org/test7
10.5555/test8,http://www.crossref.org/test8

To submit, using the web deposit form, select the ‘Supplemental Metadata Upload’ option under ‘data type’ to upload the file. Enter your log in details and email address, then submit. The .csv metadata will be converted to XML and submitted to the Crossref System.

As-crawled URLs

Mon, 01 Jan 0001 00:00:00 +0000

As-crawled URLs

Crossref metadata is often distributed to search engines and other crawler-based services that index the full text of content on a publisher’s site. For some publishers the URL associated with the DOI is appropriate for crawling, meaning the publisher’s platform recognizes the crawler’s incoming request and responds by supplying the appropriate content. If a DOI URL isn’t crawler friendly, a publisher may supply a specific URL to the indexing service by depositing as-crawled URLs.

A substantial advantage for an indexing service is the ability to associate the DOI of the item with the location at which it was indexed. Search services often index content by where it was found (URL) which may not be a stable/reliable key. Adding the DOI as an index key adds stability.

Depositing as-crawled URLs

Publishers wishing to deposit ‘as-crawled’ URLS will be required to use the Crossref deposit schema or DOI resource schema. With either schema the as-crawled URLS are specified using a <collection>. The schema provides a list indexing services. The property attribute of the <collection> tag must be set to ‘crawler-based’. The crawler property of the <item> tag is set to identify the indexing service as demonstrated in the examples below.

URL only deposit:if a DOI has already been deposited, add as-crawled URLs to the existing metadata with a URL-only deposit. + show/hide example

<?xml version="1.0" encoding="UTF-8" ?> <doi_batch version="4.3.6" xmlns="http://www.crossref.org/doi_resources_schema/4.3.6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/doi_resources_schema/4.3.6 http://www.crossref.org/schemas/doi_resources4.3.6.xsd"> <head> <doi_batch_id>123456</doi_batch_id> <depositor> <name>your name</name> <email_address>support@crossref.org</email_address> </depositor> </head> <body> <doi_resources> <doi>10.5555/sampledoi</doi> <collection property="crawler-based"> <item crawler="iParadigms"> <resource>http://www.yoururl.org/article1_.html</resource> </item> <item crawler="google"> <resource>http://www.yoururl.org/article1.html</resource> </item> <item crawler="msn"> <resource>http://www.yoururl.org/article1.html</resource> </item> <item crawler="scirus"> <resource>http://www.yoururl.org/article1.html</resource> </item> </collection> </doi_resources> </body> </doi_batch>

Metadata deposit with as-crawled URLs:as-crawled data is included in the <doi_data> element + show/hide example

<doi_data> <doi>10.5555/pubdate1</doi> <resource>http://www.yoururl.org/article1.html</resource> <collection property="crawler-based"> <item crawler="altavista"> <resource>http://www.yoururl.org/article1_altavista.html</resource> </item> <item crawler="google"> <resource>http://www.yoururl.org/article1_google.html</resource> </item> <item crawler="iParadigms"> <resource>http://www.yoururl.org/article1_crosscheck.html</resource> </item> </collection> </doi_data>

URL updates for CrossCheck indexing should set the value of the crawler attribute to iParadigms (<item crawler=“iParadigms”>). URLs for CrossCheck indexing may also be uploaded as a CSV file.

Assigning primary and alias status

Mon, 01 Jan 0001 00:00:00 +0000

Assigning primary and alias status

One way to resolve a conflict between two DOIs with identical metadata is to assign primary status to one of them and make the other one an alias.

For example, if the metadata for 10.1103/PhysRev.69.674 and 10.1103/PhysRev.69.674.2 are the same, you might assign make 10.1103/PhysRev.69.674 primary. In this case, metadata queries that match both DOIs will resolve to 10.1103/PhysRev.69.674, and DOI queries for either 10.1103/PhysRev.69.674 or 10.1103/PhysRev.69.674.2 will return results.

You can assign primary status to DOIs in conflict one by one using the system interface, or you can assign primary or alias status to multiple DOIs by uploading a .txt file.

You can confirm the conflicts have been resolved.

Assigning primary status from the system interface

To assign primary status to a DOI from the Conflict tab:

Access the Crossref system.
Click the Metadata Admin tab.
Click the Conflict tab, if necessary.
Enter either the submission ID, the conflict ID, or the DOI ID in the appropriate box.
Select Show Consolidated Conflicts, if available.
Click Submit to see the DOIs associated with the conflict.
Select the DOI that you want to make primary.
Click Make Selected DOI Primary in All Conflicts.

If you make a mistake, you can undo it by returning to this page and clicking ‘ Unresolve All Conflicts’.

The Crossref system updates the records. In this case, it makes 10.1103/PhysRev.69.674 the primary DOI.

Assigning primary or alias status by uploading conflict management submissions

To assign primary or alias status to multiple DOIs by uploading a text file. The status you assign applies to all conflicts that involve the DOIs.

To assign DOIs primary status, create a .txt file with the header ‘H:email={email address};op=primary’ for example::

H:email=your@email.address;op=primary
10.1016/0032-1028(80)90001-2
10.1016/0032-1028(80)90002-4
10.1016/0032-1028(80)90003-6
10.1016/0032-1028(80)90004-8
10.1016/0032-1028(80)90005-X
10.1016/0032-1028(80)90006-1
10.1016/0368-3281(63)90014-7

Use op=alias when the primary DOIs are not known. If there are more than two DOIs involved in the conflict, the operation is rejected because the system cannot determine which DOI to make primary.

Access the Crossref system interface(https://doi.crossref.org)
Click the Submissions tab.
Click the Upload tab, if necessary.
Locate and select the metadata file.
Select Live.
Select Conflict Management.
Click Upload.

All the DOIs listed in the file will be assigned whichever status you specified in the op element. The Crossref system will send you a message like this one for an individual DOI:

<record_diagnostic doi="10.1088/0368-3281/5/6/313"> <conflict status="Success" ids="48983,49365,49783,50243,51067"> <msg>Marked as alias</msg> <doi_list> <doi>10.1016/0368-3281(63)90014-7</doi> </doi_list> </conflict> </record_diagnostic>

or this one for multiple DOIs:

<?xml version="1.0" encoding="UTF-8"?> <doi_batch_diagnostic> <submission_id>1181263946</submission_id> <record_diagnostic doi="10.5555/prime"> <conflict status="Success" ids="23135669,2311211"> <msg>Marked as alias</msg> <doi_list> <doi>10.5555/a1</doi> <doi>10.5555/a2</doi> </doi_list> </conflict> </record_diagnostic> </doi_batch_diagnostic>

Confirm that conflicts were resolved

To double-check that any conflict associated with a DOI was eliminated:

Access the Crossref system.
Click the Metadata Admin tab.
Click the Conflict tab, if necessary.
Enter the DOI ID, such as 10.1103/PhysRev.69.674.2, in the appropriate box.
Clear all the options.
Click Submit to see whether any conflict still exists.

Another way to verify the conflict was eliminated is to query for the DOI.

Becoming a member

Mon, 01 Jan 0001 00:00:00 +0000

Becoming a member

Crossref operates a technical service on behalf of its member publishers helping them establish URL links between their content and the content of other Crossref publishers. These links primarily go from the references listed in an item’s bibliography to the item being cited by the author. Crossref services are technical in nature and require member’s staff responsible for integrating with Crossref’s offerings to have some understanding of XML and Web technologies and to have a thorough understanding of their own production processes.

Membership process

Publishers join Crossref by completing and signing the membership application and membership agreement. After joining Crossref, you receive a DOI prefix, a user name and password to access the Crossref system, and the general login to the members’ area of the Crossref web site. For information about the cost of joining Crossref as a publisher, see Publisher Fees on the Crossref web site.

Join Crossref using our membership request form.
When you become a member, you will be assigned a DOI prefix. You must establish a DOI suffix pattern before creating DOIs.
Build deposit XML for containing your DOIs and their metadata (non-technical users try our basic Web deposit form).
Add DOIs to your DOI response pages
Retrieve and construct outbound DOI links for the references in your content

Publishers may also participate in other Crossref services.

Member obligations

When participating in Crossref members are expected to:

Build and operate the necessary systems on their side which compose the XML deposit files and submit them to Crossref
add DOI links (when available) to the reference list for journal articles deposited with Crossref
Regularly monitor their transactions with Crossref, and identify and correct errors.
Remain vigilant about updating the metadata for their DOIs, particularly the URL of the resource.
Review the various Crossref reports issued to members and correct any identified errors.
Use commercially reasonable efforts to make your content available and ensure persistance of links through an authorized archive if you are no longer able to host your content.

More information on becoming a Crossref member is available on the Crossref website. For a complete list of member obligations, see Publisher Rules.

Best practice for depositing

Mon, 01 Jan 0001 00:00:00 +0000

Best practice for depositing

Depositing References: all members are encouraged to deposit references. References can be deposited as part of a metadata deposit or as a reference-only deposit.

Reference by default are not distributed with query results, but can be distributed with publisher consent. Contact support@crossref.org to enable reference distribution.

Title-level DOIs: members are strongly encouraged to deposit title-level DOIs for journals deposited with Crossref.

For electronic-only journals, you may want to include an alternate number in lieu of page numbers. In these cases, do not use the <first_page> tag; instead, use the <item_number> tag with the item_number_type attribute set accordingly:

<item_number item_number_type=“article_number”>3D9324F1-16B1-11D7-8645000102C</item_number>

First author metadata: Within the <contributors> tag, the first <person_name> or <organization> with an attribute of “sequence=first” is stored and used to match against queries. For <person_name>, the important value is in <surname> while the entire value of <organization> is used. Care should be taken to ensure that the entire person’s name, or their last name with initials, are not placed into the <surname> element.

ISSN order:The Crossref system saves every ISSN associated with a given journal title over the course of several deposits. However, the first ISSN (print and/or electronic) is what appears in the metadata database (MDDB.XML). A subsequent query using any of the ISSNs will match all the deposits regardless of which ISSN was associated with a particular item at the time of deposit.

Only one ISSN can be assigned per journal title. Contact support@crossref.org in advance of title or ISSN changes.

DOI makeup: suffixes should be short and simple and follow DOI suffix pattern guidelines

File Size: For efficient processing, keep file sizes under 150KBytes. File size should not exceed 1.5MBytes.

Large volumes of Deposits: When making a large number of back file deposits, particularly if they include references, contact Crossref for queue management support.

Deposit logs: Be sure to examine the submission log file you receive via email. If you do not get a log file when expected, you canreview your submissions using the Submission Administration function.

Timestamp: Every time a DOI is deposited it must be given a timestamp. This value is a string of text that gets interpreted as a number. The recommended format is YYYYMMDDHHMM (ex: 200810021422). Timestamps must be incremented when DOIs are updated.

Title ownership: Publication title ownership is enforced. If you have recently acquired a title, make sure Crossref is aware of the change (by following our title transfer procedures) prior to depositing for that title.

Best practice for journal titles

Mon, 01 Jan 0001 00:00:00 +0000

Best practice for journal titles

Titles in the Crossref system are created from publisher metadata with the first deposit of a journal. The publisher determines the exact title and ISSN included in the deposit.

We recognize the value of the ISSN as a unique identifier of key title information – accordingly, Crossref’s title management policies comply with the requirements provided by the ISSN centre regarding title management. Practices that directly impact Crossref deposits include:

All series (journal, book, conference proceedings) should have an ISSN.

The ISSN is crucial for identifying a serial. If you are supplying us with data for older titles that predate ISSN assignment, you should request ISSNs from your ISSN agency as they can be assigned retroactively. This isn’t only for Crossref’s convenience - libraries, database providers, and other organizations using your data will welcome (and often require) an ISSN for anything defined as a journal.

New journal titles are sometimes not assigned an ISSN until the first issue is published. Journal titles may be deposited with Crossref without ISSNs if a journal title-level DOI is included in the deposit. The title-level DOI must be consistently supplied with every deposit for the journal. The ISSN should also be included in deposits when it is assigned.

A distinct ISSN should be supplied for each distinct version of a title.

If a title changes significantly the publisher needs to get new ISSNs (both print and online). This rule is established by the International ISSN Centre, not Crossref, but we support and enforce it. Minor title changes (such as changing ‘and’ to ‘&’) don’t require a new ISSN.

Original title: Journal of Crossref Metadata
Minor change (no new ISSN required): The Journal of Crossref Metadata
Major change (new ISSN required): Journal of Crossref Metadata Quality

Online versions of journals encompassing multiple historic print titles should each be assigned distinct print and online ISSNs.

It’s common practice for publishers to publish all versions of a title as an online journal with a single ISSN. This isn’t recommended practice as it causes a lot of linking and citing confusion – you’ve essentially created two versions of a title. This is particularly confusing when volume and issue numbers overlap between title iterations.

Assign DOIs at the journal title level

Members are strongly encouraged to assign DOIs at the journal title level.

ISSN Manual, Presentation & Identification of E-Journals (NISO recommended practice)

Browsable Title List

Mon, 01 Jan 0001 00:00:00 +0000

Browsable Title List

The Browsable Title List provides an alphabetically indexed list of journals, books, and conference proceedings for which Crossref has article metadata. Browsing and searching may be limited by Genre (all, journals, books, or conference proceedings) or Search type (title, ISSN/ISBN, subject, or publisher).

When searching for a specific title, enclose the title in quotes or search by ISSN

Search results will include the following (when available):

Title (Journal/Book/Conf Proc): Title name. Journal titles are grey, book titles are green, and conference proceedings titles are purple.
Publisher: Publisher of the title as listed in the Crossref database.
Print ISSN/ISBN: ISSN or ISBN (indicated by color) of the print version of the title.
Electronic ISSN/ISBN: ISSN or ISBN (indicated by color) of the electronic version of the title.
DOI: DOI assigned at the title level.

Review results:

Click to view the year(s), volume(s), and issue(s) deposited in the Crossref system for a title.
Click to view alternate title information, abbreviated titles (if any), other ISSNs or ISBNs, subjects covered, and any coverage notes for this content item. This information is obtained from a third party and may not match data deposited with Crossref.
To request a missed-conflict report for a title, click at the far right of the row.
Lists of libraries and affiliates (associations, organizations, agents, and linking solution partners) that use Crossref are also available.
A comma-separated journal coverage list is also available for download (~7 MB file)

CMS Basic

Mon, 01 Jan 0001 00:00:00 +0000

CMS Basic

Crossref Metadata Services (CMS) is our program that provides for the bulk distribution of metadata to subscribers (affiliates and metadata services). CMS Basic is a level of service where a recipient is allowed to retrieve the metadata for all Crossref member publishers (in the enhanced level of service member publishers can opt-out thus disallowing distribution of their metadata). With CMS Basic a recipient will receive the basic bibliographic metadata for each DOI. Reference lists are excluded from CMS Basic data. CMS Basic data is retrieved by a recipient using FTP from authorized IP addresses.

Organizations that choose to host data locally pull it from Crossref in XML and can utilize all or a subset of the content delivered to Crossref. Local hosting is for those organizations that want to retrieve DOIs within their local system without using Crossref’s query service to retrieve DOIs from Crossref. Because the data is delivered in XML format, the organization must have an infrastructure to receive and load the information into its own system and databases. The structure of the CMS basic service does not allow for selective retrieval of data. All data must be transferred with filtering done after receipt.

Conditions for local hosting

Local hosting is available to all Crossref members and affiliates.
Organizations that host locally are subject to the general membership terms and any specific terms for local hosting as determined by the Crossref Board of Directors.
Organizations that host locally are not allowed to resell the data or provide a lookup service for other members’ DOIs. There is no restriction on members providing a lookup service for their own DOIs.
The annual administrative fee for local hosting is charged in addition to any other membership or deposit fees that may apply. For information about annual hosting fees, contact Crossref.
Agents appointed by members are not eligible for local hosting.
There are no individual DOI lookup charges for local hosting.

Technical Information About Local Hosting

The distribution of Crossref metadata is accomplished via FTP of XML files from the Crossref servers. FTP access to the file area is controlled by IP addresses and account authentication.

Two formats of XML are provided in CMS basic:

‘lite-weight’ XML (sample): includes basic citation metadata (journal title, ISSN, volume issue page first author) and DOIs. Lite-weight XML does not follow a schema and is very flat (data is in attributes, not an XML hierarchy) which makes it easy for some processors to handle.

Medium-weight XML (sample): basic citation metadata structured according to our output data schema (schema | documentation).

Data update schedule and organization

CMS Basic data is updated on a daily, weekly and monthly rotation.

The top level FTP directory structure has several sub folders:

Folders *compressed* and *crossref * contain deprecated CMS data (this is no longer updated).
Folders *mdByTitle* and *mdByTitle-lite* are aliased and link to lite-weight XML.
Folder *mdByTitle-medium* contains medium-weight XML, the most robust form of CMS basic data.

Under folders mdByTitle and mdByTitle-medium are sub folders that contain the rotation of regularly updated data. Each day, week and full folder contain the same substructure. Data is generated on a daily, weekly and monthly basis. Each day the prior day’s DOI deposit activity (new or update) are written to one of the ‘dayX’ folders. The process rotates through the ‘dayX’ folders during the week. Each week (on Saturday) the prior week’s deposit activity is written to one of the ‘weekX’ folders. This process rotates through the folders during the month. Once each month (on the 3rd) the entire metadata set (all DOIs for all titles) are written to the ‘full’ folder. + show/hide directory hierarchy

Also in the lite-weight folder are six text files that serve as a road-map to what is in the dayX and weekX folders. These text files tell where to find the most recent interval of data.

lastrundate_daily_books.txt
lastrundate_daily_confproc.txt
lastrundate_daily_journals.txt
lastrundate_weekly_books.txt
lastrundate_weekly_confproc.txt
lastrundate_weekly_journals.txt

The TXT files describe what run was most recently made and which folder contains the data. For example, lastrun_daily_journals.txt may contain this single line which indicates that the data for Sept 11, 2007 is in the day0 folder.

11-SEP-2007:12-SEP-2007:0

If for some reason the daily process failed the date range may span more than one day. This example shows that the deposit data for Sept 11 through Sept 13 are in ‘day0’.

11-SEP-2007:14-SEP-2007:0

The weekly files contain two lines of text. The first identifies the date the run was made and the second indicates which folder contains the data. The ‘full’ folder will be populated at the start of the month and one should use the file date/time to determine currency.

Samples

Crossref does not provide any specific tools or programs for processing these XML files but will provide technical assistance to an organization that is incorporating local hosting services into their system.
For both models of XML the data is available as single XML files or as .zip archives for each day.
Local hosting a subset of the Crossref repository can only be accommodated using the second data model.

CMS Enhanced

Mon, 01 Jan 0001 00:00:00 +0000

CMS Enhanced (OAI-PMH)

CMS Enhanced allows a recipient to retrieve the basic metadata and in addition possibly receive the list of references for any individual item. The major difference between CMS Basic and CMS Enhanced are the terms defining the allowed use of metadata obtained with each service. Because of the term differences publishers may choose to opt-out in supplying their metadata to a particular CMS Enhanced recipient. A publisher may also choose to supply basic metadata but to restrict distribution of the reference lists.

CMS Enhanced services are delivered by an OAI-PMH server operated by Crossref. Please see our help section on using this interface.

Dublin Core (DC) is the standard format for metadata distribution by a PMH compliant repository. However, DC is not expressive enough to represent the full metadata available in Crossref. DC is not currently supported by Crossref’s PMH interface. Our PMH currently generates data formatted using our Unified XML schema (schema | documentation).

Each record retrieved through the PMH interface will have the complete metadata as deposited by the publisher for that DOI. Crossref’s repository supports a three level hierarchical set organization. At the top level are the publisher sets where the set identifier is the DOI prefix for the publisher. The next level is the publication title level where the set identifier is an internal value assigned by Crossref for the publication. The third level is the year of publication.

All PMH identifiers are DOIs expressed using the IETF RFC 4452 ”The ‘info’ URI Scheme for Information Assets with Identifiers in Public Namespaces” (see the info-uri registry).

Samples

OAI-PMH query interface

CSV upload

Mon, 01 Jan 0001 00:00:00 +0000

Depositing funding and license metadata using a .csv file

Crossref now supports deposit of funding and license metadata in .csv format. Deposits are made via the web deposit form.

To submit, select the ‘Supplemental Metadata Upload’ option under ‘data type’ to upload the file. Enter your log in details and email address, then submit. The .csv metadata will be converted to XML and submitted to the Crossref System.

Some basic validation is performed upon upload. Incomplete or incorrect files will return an error message and will not be deposited. If the file passes the initial validation it will be converted to XML and submitted to the Crossref system. You will receive a submission log when your deposit is complete. Please review the log to be sure the DOIs have been updated. The initial validation addresses .csv formatting issues only, additional validation is performed upon deposit.

As-crawled URLs for CrossCheck indexing may also be submitted by CSV upload (details).

The .csv upload format is still being beta tested. Please send questions or comments to support@crossref.org. If you are reporting problems with an upload please attach the .csv file to your support request.

Updated January 12 2015: added support for MIME type.

CSV specifications

Files submitted via .csv upload must comply with these specifications:

Column headings must match the headings outlined for each deposit type. You may include funding metadata, license metadata, or both funding and license metadata.
Values must be separated by a comma.
Commas and quotation marks must not appear within a column value.
All dates must be in YYYY-MM-DD format.
If metadata is not available for an item the table cell should be left blank. If an entire column is not populated it may be omitted. Do not enter placeholders such as n/a or -, this will cause your deposit to fail or cause incorrect metadata to be attached to a DOI.

Funding metadata(funding): the .csv file must contain 4 columns with these headings:

DOI: the DOI being augmented
<funder_name>: name of the funding agency as it appears in the funder Registry
<funder_identifier>: funding agency identifier in the form of a DOI
<award_number>: grant number or other fund identifier

If a DOI has multiple funders, the DOI must be repeated for each funder. It is recommended that all available metadata is deposited. If a piece of funding metadata is not available (a grant number, for example) the field should be left blank.

download or + show / hide example

License metadata:Members may deposit license metadata to supporttext and data mining. The .csv file may contain these headings (download example):

DOI: the DOI being augmented (required)
<license_ref applies_to=“vor”>: license URL for version of record (optional)
<vor_lic_start_date>: start date of version of record license (optional)
<license_ref applies_to=“am”>: license URL for accepted manuscript (optional)
<am_lic_start_date>: start date of accepted manuscript license (optional)
<license_ref applies_to=“tdm”>: license URL for accepted manuscript (optional)
<tdm_lic_start_date>: start date of accepted manuscript license (optional)
<resource content_version=“vor”>: item URL for version of record (optional)
*<resource content_version=“vor” mime_type=“?”>*: item URL for version of record with MIME type (optional)
<resource content_version=“am”>: item* *URL for author manuscript with MIME type (optional)
*<resource content_version=“am” mime_type=“?”>*: item* *URL for author manuscript with MIME type (optional)
*<resource*>: item URL with no version type and with MIME type (optional)
*<resource mime_type=“?”>*: item URL with no version type (optional)

where “?” is the MIME type as defined in the Crossref deposit schema

Funding and license metadata: funding and license metadata may be combined into a single file. Order is important, please include columns in the order listed below (download example):

*DOI:* the DOI being augmented
<funder_name>: name of the funding agency as it appears in the funding Registry
<funder_identifier>: funding agency identifier in the form of a DOI
<award_number>: grant number or other fund identifier
<license_ref applies_to=“vor”>: license URL for version of record (optional)
<vor_lic_start_date>: start date of version of record license (optional)
<license_ref applies_to=“am”>: license URL for accepted manuscript (optional)
<am_lic_start_date>: start date of accepted manuscript license (optional)
<license_ref applies_to=“tdm”>: license URL for accepted manuscript (optional)
<tdm_lic_start_date>: start date of accepted manuscript license (optional)
<resource content_version=“vor”>: item URL for version of record (optional)
*<resource content_version=“vor” mime_type=“?”>*: item URL for version of record with MIME type (optional)
<resource content_version=“am”>: item* *URL for author manuscript with MIME type (optional)
*<resource content_version=“am” mime_type=“?”>*: item* *URL for author manuscript with MIME type (optional)

where “?” is the MIME type as defined in the Crossref deposit schema

Changing or deleting DOIs

Mon, 01 Jan 0001 00:00:00 +0000

Changing or deleting DOIs

Errors in communication or the publishing process occasionally result in printed or published DOIs not matching DOIs deposited with Crossref. Once deposited, DOIs are immediately queryable and as a result can’t be changed as they potentially may be distributed to the public. Publishers can, however, alias problematic DOIs to valid DOIs to correct the problem.

For example, Publisher A deposits DOIs for Journal A according to their usual standards. Their typesetter mistakes 1 for l in all DOIs of a single issue. To correct:

Deposit the misprinted DOIs.
- Metadata for a misprinted DOI does not need to be complete, since it will be aliased to a DOI with complete metadata.
Create and submit a forced alias file:

H:email=youremail@address.com;op=force_alias;delim=tab
10.xxxx/primary1 10.xxxx/alias1
10.xxxx/primary2 10.xxxx/alias2
10.xxxx/primary3 10.xxxx/alias3

The primary DOI is the correct DOI. The alias DOI is the misprinted (or otherwise incorrect) DOI.

Deleting DOIs

DOIs are sometimes deposited in error - either the content does not exist, or the publisher is not authorized to create DOIs for that content. DOIs for items that have been retracted or otherwise withdrawn should be directed to the appropriate notice on the publisher’s website.

Crossref is not able to fully delete DOIs but will, in select circumstances, direct DOIs to a deleted DOI page. The metadata for the DOI will also be updated to disconnect the DOI from any identifying metadata. This process should only be applied to DOIs that have not been distributed or otherwise used for linking.

Cited-by linking overview

Mon, 01 Jan 0001 00:00:00 +0000

Cited-by linking overview

In addition to using DOIs to link to references that appear in their content, Crossref members can retrieve the DOIs of other publications that cite their content. This optional service, called cited-by linking (previouslyforward linking), enables Crossref members to display cited-by links in the primary content that they publish. Cited-by linking policies, examples, and a list of participating publishers are available on the Crossref website.

Cited-by linking process:

Publisher A registers DOI 10.1234/X for article X with the following metadata:

Journal= “Good Science”, author=“John Smith”, volume=“21”, first page=“100” year=“2007”
Publisher B deposits metadata for article Y and assigns it DOI 10.5678/Y. The deposited references for article Y include the following:

<citation_list> <citation key="reference to article X"> <author>Smith</author> <journal_title>Good Science</journal_title> <cYear>2007</cYear> <first_page>100</first_page> <volume>21</volume> </citation> </citation_list>
The Crossref system establishes a cited-by relationship between article X and Y
Publisher A later sends a query asking who ‘cites’ article X and is given the DOI for article Y and its metadata.

Currently only the publisher who owns an item may ask for the cited-by data. So in the above example publisher C could not inquire about the cited-by relationship of article X or Y. Obviously the order of events may differ than this simple example shows, for example step #2 could occur before step #1. The Crossref system is setup to handle this by ‘remembering’ the citation in article Y and will establish the relationship whenever article X is ultimately deposited.

Steps for cited-by linking participation:

Deposit references: References can be submitted as part of a metadata deposit or as a reference-only deposit. See Depositing references for details.
Query for cited-by links:cited-by matches can be retrieved via XML and HTTP querying. See Retrieving cited-by links for details.
Once retrieved, cited-by links should be included on DOI response pages. + show/hide example

Response page (from http://dx.doi.org/10.1088/1367-2630/1/1/006)

To make use of cited-by linking, publishers must first register for the optional cited-by linking service.

Components

Mon, 01 Jan 0001 00:00:00 +0000

Components

DOIs may be assigned to items that are part of a journal article, book chapter, or any other content item. A component would typically be a figure, table, or image which is part of or referred to by the parent item. Assigning a DOI to a component allows direct linking to the component item.

Depositing Components

Components have their own metadata which is separate from that of the parent DOI(s). They may be deposited with the parent DOI as part of a metadata deposit (schema documentation), or in a separate deposit using the sa_component element in the 4.3.0 schema. Components may belong to more than one parent item. For example, two journal articles may include the same component DOI.

Sample stand-alone component deposit
Sample journal article deposit containing a component (last article in example)

Querying for Components

Currently there is no support for querying Crossref to discover components but a list of components belonging to a given (parent) DOI may be retrieved using an XML query with the list-components attribute set to “true”, for example:

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address></email_address> <doi_batch_id>SomeTrackingID1</doi_batch_id> </head> <body> <query key="MyKey1" list-components="true"> <doi>10.50505/2008TESTONE</doi> </query> </body> </query_batch>

Conflict report

Mon, 01 Jan 0001 00:00:00 +0000

Examining the Conflict report

The Conflict report shows you the name and size of the file that contains your organization’s conflict information, the total number of publications your organization has registered, and the total number of conflicts that exist in the Crossref system for your organization. If you click your organization’s name, you can also see the name of each publication, the total number of DOIs registered for each publication, and the total size of the file storing the information about each journal deposited by the member.

To see details about all your organization’s conflicts, click the name of the XML file, as shown here:

The XML file will list every conflict for the selected prefix. You may examine the conflicts for a particular publication by clicking on the title. This will display a text file such as the following:

where:

ConfID is the unique ID number for the conflict.
CauseID is the deposit submission of the DOI causing the conflict.
OtherID is the deposit submission of the affected DOI.
JT is the publication’s title.
MDis metadata for the DOIs.Metadata for DOIs in conflict will be the same.
DOI is the DOI involved in the conflict.
Parenthetical value following the DOI (in this case, 1686-null) lists all the conflicts in which the DOI is involved and the resolution status of that conflict.
ALERT, if it appears, indicates that the DOIs have more than one conflict, which can occur if they were deposited repeatedly with the same metadata. This field lists the other conflict IDs and their status:
- null – Not resolved
- A – Made an alias
- P – Made a prime
- U – Resolved by a metadata update
- R – Manually erased or resolved

You can also view detailed information about individual conflicts using the web interface.

Content negotiation

Mon, 01 Jan 0001 00:00:00 +0000

Content negotiation for DOIs

Crossref and DataCite support content negotiated DOIs via http://data.crossref.org and http://data.datacite.org. See http://crosscite.org/cn/ for details.

Examples using curl:

curl -D - -L -H “Accept: application/rdf+xml” “http://dx.doi.org/10.1126/science.1157784"

curl -D - -L -H “Accept: text/turtle” “http://dx.doi.org/10.1126/science.1157784"

curl -D - -L -H “Accept: application/atom+xml” “http://dx.doi.org/10.1126/science.1157784"

The Crossref-specific ‘unixref’ format can be used as well:

curl -D - -L -H “Accept: application/unixref+xml” “http://dx.doi.org/10.1126/science.1157784"

Behind the scene details most people don’t need to know.

All prefixes assigned by Crossref have had their default content negotiation set within in Handle to use Crossref’s content negotiation proxy. This is done by assigning an HS_NAMESPACE property on the prefix’s record in Handle (automatically done by the Handle system whenever Crossref creates a new prefix on behalf of a member).

20 HS_NAMESPACE Wed Feb 23 2011 17:17:15 EST <HS_NAMESPACE>
<DOI.RA>0.SERV/10.crossref</DOI.RA>
<locs>0.SERV/10.crossref</locs>
</HS_NAMESPACE>

This points to the Handle record 0.SERV/10.crossref where location properties are set (see The DOI Handbook). In that record there is a property that specifies that for http role “content negotiation” the DOI proxy should redirect to data.crossref.org.

4 10320/loc Tue Mar 15 2011 12:54:15 EDT <locations>
<location weight=“0” http_role=“conneg” href_template=“http://data.crossref.org/{hdl}" />
<xlocation weight=“0” role=“metadata” href_template=“http://metadata.labs.crossref.org/?dois={hdl}&format=unixref" />
</locations>

If a Crossref member would instead like to perform their own content negotiation for their DOIs they should ask that Crossref modify the Handle record for their prefix.

Example, for Wiley’s prefix 10.1002 we would change the HS_NAMESPACE value on 0.NA/10.1002 to:

20 HS_NAMESPACE Wed Feb 23 2011 17:17:15 EST <HS_NAMESPACE>
<DOI.RA>0.SERV/10.crossref</DOI.RA>
<locs>0.NA/10.1002</locs>
</HS_NAMESPACE>

and add:

4 10320/loc Tue Mar 15 2011 12:54:15 EDT <locations>
<location weight=“0” http_role=“conneg” href_template=“http://cnproxy.wiley.com/{hdl}" />
</locations>

Controlling query execution

Mon, 01 Jan 0001 00:00:00 +0000

Controlling query execution

Many query elements have optional properties that control how a query is executed by the system. The Crossref query engine operates by evaluating several logic rules in series. Each rule focuses on certain fields in the query with the first rule processing the entire query. If any rule returns a single DOI as its output, this DOI is taken as the result for the query, and rule processing terminates.

Query control attributes are described in detail in the table below. These controls include:

Match:use to specify level of fuzzy or exact matching. This attribute may be applied to several elements (ISSN, author, issue, article_title)
Enable-multiple-hits: allows or prevents matches returning more than one DOI
Secondary-query: instructs the system to perform a specific query if the default query mode does not produce a result. Current options include author/title, multiple hits, and author/title multiple hits.

Element attribute values

Element Property Value Purpose

query key string to track a query to its results enable-multiple-hits false (default) have the system reduce the query to one DOI and return nothing if it can not do so true have the system return one DOI for each query rule it executes multi_hit_per_rule have the system return many DOIs for each query rule it executes - will produce up to 50 candidate DOIs which partially match the query exact forward-match false (default) No query is stored true Stored this query and re-run it automatically and notify via email any matches that are found list-components false (default) Components not included in results true list the DOIs of any components that have deposited which are linked to this DOI expanded-results false(default) true include article title in the results (only applicable when results format=XML_XSD) secondary-query author-title perform author-title search if metadata search fails multiple-hits returns multiple hits (if present) author-title-multiple-hits performs author/title and multiple hits search if initial search fails issn match optional value may be missing from deposited metadata exact match exactly as it appears in the query journal_title optional not required fuzzy(default) use fuzzy string matching exact match exactly as it appears in the query author match optional instructs the query engine that this field may be ignored. fuzzy (default) use fuzzy string matching null match if author is missing in the metadata exact match exactly as it appears in the query issue match fuzzy(default)/exact – see above – first_page fuzzy(default)/exact – see above – year optional(default)/exact – see above – article_title match fuzzy(default)/exact – see above –

Creating a DOI suffix pattern

Mon, 01 Jan 0001 00:00:00 +0000

Establishing a DOI suffix pattern

Before you can assign DOIs to articles or other content items, you must devise a DOI assignment scheme. Crossref gives you a DOI prefix that you must use, but you can create your own pattern and system for suffixes.

The DOI suffix has a very flexible syntax. It can be any alphanumeric string, consisting of a single node or multiple nodes. A node is a portion of a character string. A single node has no delimiters (periods, colons, pipes, and so on), for example: 123456. A character string with multiple nodes must include a delimiter (a period, colon, pipe, and so on) between each one, for example: 12.34.56. Each suffix must be unique within a prefix.

Because the DOI is an opaque string intended to remain unique and persistent throughout changes in ownership and location of the content, you do not need to include any specific or descriptive information in the DOI. Such information forms the metadata associated with each DOI, which is submitted along with the DOI and URL. If you choose to include such bibliographic information in a DOI string, it will have no meaning within the Crossref or DOI system. Existing identifiers can also be used for the DOI suffix, such as an ISBN, PII (personally identifying information), or existing internal numbering scheme.

Sample suffix patterns

Crossref members have established a variety of schemes for creating their DOI suffixes. One or more of these patterns may be appropriate for your situation: Sample DOI suffix patterns

Guidelines

Be concise: Make the suffix as concise as possible to facilitate human readability. Remember, DOIs will appear online and in print; users will also re-type DOIs.
Be unique:A suffix must be unique within a given prefix.
Be case insensitive: A suffix is case insensitive, so 10.1006/abc is the same as 10.1006/ABC.
Be consistent: The suffix should reflect a consistent, logical system that can be easily documented and readily understood by employees of your organization, so that the task of assigning DOIs can be passed from one employee to the next. For example, you might want the suffix to include existing internal identifiers.
Avoid page numbers: It is possible to use traditional bibliographic metadata (such as journal, volume, and page) in constructing DOI suffixes because both this metadata and the DOI are persistent. However, some issues need careful consideration before choosing such an approach. DOIs should be active as soon as articles appear online. Choosing a scheme that is tied to page numbers makes it difficult to put content online before pagination is complete for a print version or if the items are published online only.
Only use approved characters: “a-z”, “A-Z”, “0-9” and “-._;()/”
Use one or more nodes: You can use suffix nodes to reflect hierarchical information or levels of granularity. For example, the first node might be a multiple-letter code for the journal title, while successive nodes encode the year of article acceptance and the order of article acceptance. This is the scheme used by Academic Press, with resulting DOIs such as 10.1006/jmbi.1998.2354.
Make suffixes extensible: DOI suffixes should be extensible. In the future, for instance, parts of articles, such as figures, graphs, and supplementary materials, might be assigned DOIs. Using the preceding Academic Press example, the second figure in the article might be assigned this DOI: 10.1006/jmbi.1998.2354.f002. DOIs are case-insensitive: 10.5555/ABC123 is the same DOI as 10.5555/abc123
An expanded set of characters was supported prior to 2008. DOIs created before the character set was restricted are still supported, but members are not able to create new DOIs with these characters.
DSpace repositories should review DOIs and DSpace repositories before constructing a DOI suffix pattern

Creating response pages

Mon, 01 Jan 0001 00:00:00 +0000

Creating response pages

When metadata and DOIs are deposited with Crossref, the publisher must have active response pages so that incoming links can be received. As soon as metadata and DOIs are deposited in Crossref, users will be able to retrieve the DOIs and create links. Most Crossref publishers take users to the abstract page and permit authenticated users to access the full text automatically. If the full text is available at no charge, users can access it immediately. Many publishers also present unauthenticated users with pay-per-view options.

A minimal response page consists of a full bibliographic citation, including the DOI, displayed to the user. The DOI should be displayed as a URL. Additionally, a response page must display some mechanism by which the user can access the full text. Access to the full text is completely controlled by the publisher but the response page must be accessible to anyone. Crossref highly encourages including a full abstract.

Sample response pages:

Response page (from http://dx.doi.org/10.1115/1.2803632)

Response page (from http://dx.doi.org/10.1364/JOSAB.1.000354)

Crossref DOI display guidelines are available here. The guidelines recommend that Crossref DOIs always be displayed as a permanent URL.

CrossCheck

Mon, 01 Jan 0001 00:00:00 +0000

CrossCheck information is available on the Crossref website.

See As-crawled URLs for instructions on adding URLs for CrossCheck indexing to your metadata deposits.

Crossmark

Mon, 01 Jan 0001 00:00:00 +0000

For technical information and help with implementing Crossmark, please visit the Crossmark Support Site.

Crossmark

Mon, 01 Jan 0001 00:00:00 +0000

Crossmark information is available on the Crossmark website and on the Crossmark support site.

Crossref DOI Display Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

Crossref DOI Display Guidelines

Crossref DOIs should always be displayed as permanent URLs in the online environment.

Example: http://dx.doi.org/10.1006/jmbi.1995.0238

Crossref recommends that Crossref DOIs be displayed in this form online wherever bibliographic information about a piece of content is displayed.

Crossref DOIs must be displayed on members’ response pages (sometimes called landing pages). Crossref recommends that Crossref DOIs also be displayed or distributed in the following contexts:

Tables of contents
Abstracts
Full text HTML and PDF articles and other scholarly documents
Citation downloads to reference management systems
Metadata feeds to third parties
“How to Cite This” instructions on content pages
Social networking links
Anywhere users are directed to a permanent, stable, or persistent link to the content

IMPORTANT: Please make sure that no matter how you display the Crossref DOI- the DOI is easily copyable and paste-able. Some HTML widgets, javascripts and stylesheets may inadvertently break DOIs by subtly reformatting them with non-breaking spaces or other invisible (non-printing) characters. This blog post by Phillip Lord decribes the issue in detail.

CROSSREF DOIS IN CITATION REFERENCE LISTS

Crossref DOI links must—as an obligation of Crossref membership—be included in members’ online journal citation lists. Whenever possible Crossref DOI links should also be included in citations in other types of scholarly content. They can be displayed in several ways, depending on the publisher’s preference and publication style. Crossref recommends the following options:

Option 1—Use the Crossref DOI URL as the permanent link

Example:

Ghosh, M.K., M.L. Harter. 2003. A viral mechanism for remodeling chromatin structure in G0 cells. Mol. Cell. 12:255–260, http://dx.doi.org/10.1016/S1097-2765(03)00225-9

Option 2—Use a ShortDOI as the permanent link

See below for more on ShortDOIs.

Example:

Ghosh, M.K., M.L. Harter. 2003. A viral mechanism for remodeling chromatin structure in G0 cells. Mol. Cell. 12:255–260, http://doi.org/bm6

Option 3—Display the text “Crossref” with a permanent DOI link behind the text

Example: {.h5_2}

Ghosh, M.K., M.L. Harter. 2003. A viral mechanism for remodeling chromatin structure in G0 cells. Mol. Cell. 12:255–260, Crossref.

Option 4—Display the words “Full Text” or “Article” or something similar with the permanent DOI link behind the text.

Example:

Ghosh, M.K., M.L. Harter. 2003. A viral mechanism for remodeling chromatin structure in G0 cells. Mol. Cell. 12:255–260, Article.

SHORTDOI

For example, for the DOI http://dx.doi.org/10.1016/S1097-2765(03)00225-9 the short form is http://doi.org/bm6.

A benefit of the ShortDOI service is that only one ShortDOI is created for each DOI Name and the ShortDOI returns exactly the same results as the DOI name. For more information go to http://shortdoi.org/.

PERMANENT CITATION LINKS

Crossref members should always use the Crossref DOI as a permanent citation link to content for which a Crossref DOIs has been assigned. Crossref members should not use proprietary, internal or other non-DOI URLs in citation downloads, metadata feeds to third parties or in instructions to researchers on how to cite a document. Crossref members should also avoid using the term “permalink” to refer to links to content registered with Crossref since this term is commonly used for more ephemeral blog posts.

BACKGROUND

Previously, Crossref recommended that DOIs be displayed in the format doi:10.NNNN/doisuffix

At the time that the DOI system was first envisioned, it was thought that doi: would become native to browsers and automatically resolve DOIs. It appears unlikely that that will happen.

Advantages to changing the display to a resolvable URL include the following:

Users will more easily recognize Crossref DOIs as an actionable link, regardless of whether they know about DOIs.
Users who do not know how to right-click on the link and choose “Copy Link”, will still be able to easily copy the http URI
Programs (e.g. bots, etc.) will recognize the DOI as a link.

FAQ: DOI display guidelines

Crossref Metadata Services (CMS)

Mon, 01 Jan 0001 00:00:00 +0000

Metadata Services (CMS)

Crossref Metadata Services (CMS) is our program that provides for the bulk distribution of metadata to subscribers (affiliates and metadata services). Crossref offers two levels of metadata services: CMS Basic and CMS enhanced.

CMS Basic is a level of service where a recipient is allowed to retrieve the metadata for all Crossref member publishers (in the enhanced level of service member publishers can opt-out thus disallowing distribution of their metadata). With CMS Basic a recipient will receive the basic bibliographic metadata for each DOI. Reference lists are excluded from CMS Basic data. CMS Basic data is retrieved by FTP.

CMS Enhanced allows a recipient to retrieve all bibliographic metadata for items deposited with Crossref. Funding, license, and Crossmark metadata is included when available. Reference lists are included when available with some exceptions. Publishers may choose to opt-out of supplying their metadata to a particular CMS Enhanced recipient, or choose to supply basic metadata but to restrict distribution of the reference lists. CMS Enhanced services are delivered by an OAI-PMH server operated by Crossref.

Information on becoming a CMS subscriber is available on the Crossref website.

Crossref for researchers

Mon, 01 Jan 0001 00:00:00 +0000

Researchers

Crossref and Crossref DOIs primarily benefit the scholarly community by providing a somewhat invisible service behind the linking of references. While Crossref’s primary direct users are organizations, we do have tools intended for use by the general public and specifically researchers and authors. Using these tools, authors can retrieve DOIs for use in reference lists; and educators, researchers and librarians can retrieve DOIs to provide durable links in reading lists, bibliographies, and study guides.

Info for researchers on the Crossref website, User interfaces

Crossref publishers and titles

Mon, 01 Jan 0001 00:00:00 +0000

Crossref publishers and titles

Crossref has hundreds of participating publishers depositing for thousands of journals, book, conference proceedings, working papers, dissertations/thesis and databases. Please use the links below to find out who they are and what publications are represented.

View a list of the publishers that use Crossref DOIs
Use the browsable title list to view a list of the titles for which Crossref DOIs have been deposited

Lists of libraries and affiliates (associations, organizations, agents, and linking solution partners) that use Crossref are also available.

Crossref schema

Mon, 01 Jan 0001 00:00:00 +0000

Crossref Schema

Type

Version

Location

Documentation

Deposit Schema

Item metadata deposits: Use for all deposits including standalone components for a parent DOI.

4.3.6

xmlns: http://www.crossref.org/schema/4.3.6

http://www.crossref.org/schemas/crossref4.3.6.xsd

available

4.3.5

xmlns: http://www.crossref.org/schema/4.3.5

http://www.crossref.org/schemas/crossref4.3.5.xsd

available

funding: contains funding deposit specifications, used with version 4.3.1 and later

http://www.crossref.org/schemas/fundref.xsd

AccessIndicators:contains Access Indicators deposit specifications, used with version 4.3.2 and later

http://www.crossref.org/schemas/AccessIndicators.xsd

Relations:establish relationships between DOIs and other identifiers, used with version 4.3.5 and later

http://www.crossref.org/schemas/relations.xsd

Citation or resource metadata: Used for depositing additional data related to a DOI without having to supply the main metadata for the DOI.

4.3.5

xmlns:http://www.crossref.org/doi_resources_schema/4.3.5

http://www.crossref.org/schemas/doi_resources4.3.5.xsd

available

Common element: File that contains common elements used by other schema

4.3.6

http://www.crossref.org/schemas/common4.3.6.xsd

4.3.5

http://www.crossref.org/schemas/common4.3.5.xsd

Query schema

XML Query schema: Used to input XML queries to the system

2.0

xmlns: http://www.crossref.org/qschema/2.0 http://www.crossref.org/schemas/crossref_query_input2.0.xsd

available

XML Query results schema: Returns query results in the XSD_XML format

2.0

xmlns: http://www.crossref.org/qrschema/2.0 http://www.crossref.org/schemas/crossref_query_output2.0.xsd

available

UNIXSD XML schema: Returns query results in the UNIXSD format

3.0

xmlns: http://www.crossref.org/qrschema/3.0

http://www.crossref.org/schemas/crossref_query_output3.0.xsd

available

Unified XML schema: Returns query results in the UNIXML format, also used to support the data delivered by our OAI-PMH service.

1.1

xmlns: http://www.crossref.org/xschema/1.1 http://www.crossref.org/schemas/unixref1.1.xsd

available

Note:The majority of UNIXML results use the unixref1.1.xsd schema. Some results involving book or conference proceeding data deposited prior to a deposit schema change use unixref1.0.xsd.

1.0

xmlns: http://www.crossref.org/xschema/1.0

http://www.crossref.org/schemas/unixref1.0.xsd

available

Crossref output schema: Used to support data files generated for local hosting and other bulk data distribution.

3.0.1

xmlns=http://www.crossref.org/output/3.0 http://www.crossref.org/schemas/crossref_output3.0.1.xsd

available

Crossref’s OAI-PMH server generates data that is not consistent with the published open-archives OAI 2.0 schema (see http://www.openarchives.org/) because DOIs allow characters that are not allowed by xsd:anyURI.

Published OAI 2.0 schema:<simpleType name=“identifierType”> <restriction base=“anyURI”/> </simpleType>

Crossref OAI 2.0 schema:<simpleType name=“identifierType”> <restriction base=“string”/> </simpleType>

2.0

xmlns:oai=http://www.openarchives.org/OAI/2.0/ http://www.crossref.org/schemas/OAI-PMH.cr.xsd

available

Crossref user interfaces

Mon, 01 Jan 0001 00:00:00 +0000

Crossref User Interfaces

Although most interactions with Crossref’s services follow a machine-to-machine transaction model, some user interfaces are available. As Crossref has grown, many smaller publishers, affiliates, and libraries have requested simpler and, in some cases, manual ways to interact with the Crossref system.

User interfaces include:

Crossref system interface:web interface for the Crossref system
Web Deposit form:enter metadata to create deposit XML
Simple Text query form: Cut-and-paste a reference list into the form, and retrieve results. This services requires a valid email address, register for a Crossref Query Services account here.
Reference deposit: deposit references using the Simple Text query form.
Crossref Metadata Search: Most Crossref query interfaces exist to return one correct DOI match, and will only return a DOI if fairly strict requirements are met. This interface is the exception - any results containing the entered search terms will be returned. Search by full citation, title (or fragments of a title), authors, ISSN, ORCID, DOI (to retrieve metadata) and more.
Turn a Crossref DOI into a formatted reference: enter a DOI and retrieve a formatted reference. Reference quality is determined by the metadata deposited for the DOI. (more info from Crossref Labs)

DOI Conflicts policy

Mon, 01 Jan 0001 00:00:00 +0000

DOI Conflicts: definition, management and penalty fee policy

Definition

It is Crossref policy that only one DOI be created for a given work. However, it is very difficult to prevent the assignment of multiple DOIs to the same work owing to the reliability and consistency of the metadata provided in a deposit and to accepted publisher practices.

A conflict exists when two or more DOIs have been assigned to the same logical work as represented by identical metadata or when subtle metadata differences may exist (e.g. a slight variation in the publication title or style differences in the item title).

Management

System identified conflicts

The Crossref system attempts to automatically identify a conflict upon deposit of the second (or later) DOI name. This function looks for exact duplication in the deposited metadata (journal | author | volume | issue | page | year | article-title) with that of a pre-existing DOI name. Omitted metadata is not included in the comparison thus two DOI names for the same article where one omits page number will not produce a system identified conflict.

After making a deposit you will receive an XML log showing the results of the deposit process. System identified conflicts will be indicated as follows:

<record_diagnostic status="Warning"> <doi>10.1007/s10530-007-9098-9</doi> <msg>Added with conflict</msg> <conflict_id>345585</conflict_id> <dois_in_conflict> <doi>10.1007/s10530-006-9073-x</doi> </dois_in_conflict>

Once a week an on-line report is generated that list all known unresolved system conflicts (http://www.crossref.org/06members/59conflict.html). In addition emails are periodically sent out to publisher technical contacts.

Repair of system identified conflicts

System identified conflicts where all DOIs are owned by the same publisher may be repaired by the publisher themselves. This is done either by using the user interface on doi.crossref.org (Metadata Admin -> Conflicts) or by uploading batch files to the system (ref. http://help.crossref.org/#resolving-conflicts). Conflicts which involve DOI names owned by more than one publisher require the intervention of Crossref staff

Non-system identified conflicts

Since not all conflicts can be identified automatically by the system during deposit we have developed a secondary tool called the ‘Missed Conflict Checker’. This tool is available from the Browsable Title List (http://www.crossref.org/titleList) where you can lookup which titles are held by Crossref. Once a journal title is found you may select the icon to run a missed conflict report. This report may be run on multiple journal titles at the same time. The tool uses a less strict comparison and produces a report needing careful manual investigation.

Repair of non-system identified conflicts

Since by definition there is no system conflict to resolve the only repair solution is to use the forced prime/alias feature that is available using the batch upload process described above.

Preventative Measures

Crossref strives to prevent conflicts from being created. One major resource to employ in this endeavor is the system’s title ownership (aka. title lock-down) feature. This feature limits DOI name deposits to one publisher (the publication owner). Currently any new publication created is assigned ownership to the publisher creating the first DOI name. This helps to prevent accidental creation of duplicative DOI names.

Penalty fee

In July of 2007 the Crossref board approved a penalty fee (set at \$2/conflict) to be levied against the creator of conflicts under certain conditions. The following situations, with the exception conditions listed below, will result in the penalty fee being assessed. In cases of title ownership transfer it is the responsibility of the acquiring publisher to determine if DOI names already exist for items and to re-use them.

After having acquired ownership of a publication a publisher deposits new DOI names for items (e.g. articles) that were already assigned DOI names by the former owner.
Upon moving to a new hosting platform, if the new platform automatically assigns new DOI names to items which were already assigned DOI names by the former hosting platform.
If a publication is co-hosted on multiple platforms or by multiple publishers and both parties using separate prefixes deposit DOI names for the same items
If the conflict is a non-system identified conflict which is brought to the attention of Crossref staff by a third party or discovered by Crossref staff.

Exception conditions:

If a conflict is created where all DOI names involved are of the same prefix and /or owner and the depositing member resolves the conflicts without involvement from Crossref staff.

Appeals

If a member feels a levied fee is inappropriate review escalation will be 1) Director of Technology, 2) Executive Director, 3) Metadata Quality Committee and 4) the Crossref board of Directors.

What are conflicts?, Resolving conflicts

DOI Crawler

Mon, 01 Jan 0001 00:00:00 +0000

DOI Crawler Report

Crossref tests a broad sample of DOIs to ensure resolution. For each journal crawled, a sample of DOIs that equals 5% of the total DOIs for the journal up to a maximum of 50 DOIs is selected. The selected DOIs span prefixes and issues.

The results are recorded in Crawler reports, which are accessed from the Depositor Report expanded view. If a title has been crawled, the last crawl date is shown in the appropriate column. Crawled DOIs that generate errors will appear as a bold link:

Select the ‘Last Crawl Date’ link to view a Crawler Status Report for a title. + show/hide status report

The Crawler Status Report lists the following:

Total DOIs: Total number of DOI names for the title in system on last crawl date
Checked: number of DOIs crawled
Confirmed: crawler found both DOI and article title on response page
Semi-confirmed: crawler found either DOI or article title on response page
Not Confirmed: crawler did not find DOI or article title on response page
Bad:page contains known phrases indicating article is not available (for example: article not found, no longer available)
Login Page: crawler is prompted to log in, no article title or DOI
Exception:indicates error in crawler code
httpCode:resolution attempt results in error(400, 403, 404, 500, etc.)
httpFailure:http server connection failed

Select each number to view details. Select ’Re-Crawl’ and enter an email address to crawl again.

DOI Error report

Mon, 01 Jan 0001 00:00:00 +0000

DOI Error report

The DOI Error report collects unresolving DOI errors reported by end users. When a user attempts to resolve a DOI that has not been deposited, they are delivered to a web form which allows the user to submit information about the DOI they are trying to resolve: + show/hide example

The data submitted is collected by Crossref and redistributed nightly via an emailed report to the appropriate publishers. The reported errors are captured in a .csv file and contain the following data:

DOI: the DOI being reported
URL: the referring URL (if supplied)
REPORTED-DATE: date the DOI was initially reported
USER-EMAIL: email of the reporter (if supplied)
COMMENTS: comments are optional

DOI errors are reported for a number of reasons:

a DOI has been published but not deposited
the published DOI does not match the deposited DOI
a DOI has been deposited but does not resolve to the correct item
the end user misinterpreted or mistyped a DOI (i.e. confusing 1 for l or 0 for O)

Any legitimate DOIs found in this report should be deposited immediately. When a DOI is deposited, any users who reported the DOI as undeposited and supplied an email address will be notified via automated email that the DOI is now resolving.

The recipient for these reports is determined by the DOI prefix.
The total number of failed DOI resolution attempts by prefix is captured in the Resolution report.
Crossref retains reported errors and can compile a report of all DOI errors submitted by prefix if needed.

DOI Registration Agency tool

Mon, 01 Jan 0001 00:00:00 +0000

DOI Registration Agency tool

This tool identifies which DOI Registration Agency is responsible for a DOI or set of DOIs. Not all DOIs are registered by Crossref - Crossref is one of a number of DOI Registration Agencies.

Single DOI:

Prepend the DOI with *http://doi.crossref.org/doiRA?doi=* for example:

http://doi.crossref.org/doiRA?doi=10.5240/B1FA-0EEC-C316-3316-3A73-L

Multiple DOIs:

To retrieve results for multiple DOIs, include multiple doi parameters:

http://doi.crossref.org/doiRA?doi=10.1594/PANGAEA.57055&doi=10.1037/0003-066X.59.1.29&doi=10.5240/B1FA-0EEC-C316-3316-3A73-L

Results:

The results include the DOI and Registration Agency:

[
{
“DOI”: “10.5240\/B1FA-0EEC-C316-3316-3A73-L”,
“RA”: “EIDR”
}]

DOI-to-metadata query

Mon, 01 Jan 0001 00:00:00 +0000

DOI-to-metadata query

Metadata may be retrieved for all Crossref DOIs. Most DOI-to-metadata queries are done via HTTP using synchronous HTTP queries but may also be submitted as asynchronous batch queries or (for non-technical users) via a web form.

Sample HTTP Queries:

https://doi.crossref.org/search/doi?pid=&format=unixsd&doi=<DOI>

https://doi.crossref.org/servlet/query?pid=&format=unixref&id=<DOI>

Open URL query:

Crossref supports DOI queries formatted as OpenURL version 0.1 requests.

https://www.crossref.org/openurl/?pid=&format=unixref&id=doi:10.1577/H02-043&noredirect=true

For complete metadata (UNIXREF format), submit your request with format=“unixref”

Results:

Default (xsd_xml) format + show/hide {style=“margin-left: 40px; “}

<crossref_result version="2.0" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 http://www.crossref.org/schema/queryResultSchema/crossref_query_output2.0.xsd" xmlns="http://www.crossref.org/qrschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <query_result> <head> <doi_batch_id>none</doi_batch_id> </head> <body> <query status="resolved" fl_count="6"> <doi type="journal_article">10.1577/H02-043</doi> <issn type="print">0899-7659</issn> <issn type="electronic">1548-8667</issn> <journal_title>Journal of Aquatic Animal Health</journal_title> <contributors> <contributor sequence="first" contributor_role="author"> <given_name>John P.</given_name> <surname>Hawke</surname> </contributor> <contributor sequence="additional" contributor_role="author"> <given_name>Ronald L.</given_name> <surname>Thune</surname> </contributor> <contributor sequence="additional" contributor_role="author"> <given_name>Richard K.</given_name> <surname>Cooper</surname> </contributor> <contributor sequence="additional" contributor_role="author"> <given_name>Erika</given_name> <surname>Judice</surname> </contributor> <contributor sequence="additional" contributor_role="author"> <given_name>Maria</given_name> <surname>Kelly-Smith</surname> </contributor> </contributors> <volume>15</volume> <issue>3</issue> <first_page>189</first_page> <last_page>201</last_page> <year media_type="print">2003</year> <publication_type>full_text</publication_type> <article_title>Molecular and Phenotypic Characterization of Strains ofPhotobacterium damselaesubsp.piscicidaIsolated from Hybrid Striped Bass Cultured in Louisiana, USA</article_title> </query> </body> </query_result> </crossref_result>

UNIXREF format + show/hide {style=“margin-left: 40px; “}

<doi_records> <doi_record owner="10.1080" timestamp="2011-12-08 13:28:43"> <crossref> <journal> <journal_metadata language="en"> <full_title>Journal of Aquatic Animal Health</full_title> <abbrev_title>Journal of Aquatic Animal Health</abbrev_title> <issn media_type="print">0899-7659</issn> <issn media_type="electronic">1548-8667</issn> </journal_metadata> <journal_issue> <publication_date media_type="print"> <month>09</month> <year>2003</year> </publication_date> <journal_volume> <volume>15</volume> </journal_volume> <issue>3</issue> </journal_issue> <journal_article publication_type="full_text"> <titles> <title> Molecular and Phenotypic Characterization of Strains of <i>Photobacterium damselae</i>

subsp. <i>piscicida</i>

Isolated from Hybrid Striped Bass Cultured in Louisiana, USA </title> </titles> <contributors> <person_name sequence="first" contributor_role="author"> <given_name>John P.</given_name> <surname>Hawke</surname> </person_name> <person_name sequence="additional" contributor_role="author"> <given_name>Ronald L.</given_name> <surname>Thune</surname> </person_name> <person_name sequence="additional" contributor_role="author"> <given_name>Richard K.</given_name> <surname>Cooper</surname> </person_name> <person_name sequence="additional" contributor_role="author"> <given_name>Erika</given_name> <surname>Judice</surname> </person_name> <person_name sequence="additional" contributor_role="author"> <given_name>Maria</given_name> <surname>Kelly-Smith</surname> </person_name> </contributors> <publication_date media_type="print"> <month>09</month> <year>2003</year> </publication_date> <pages> <first_page>189</first_page> <last_page>201</last_page> </pages> <publisher_item> <item_number item_number_type="sequence-number">1</item_number> <identifier id_type="doi">10.1577/H02-043</identifier> </publisher_item> <doi_data> <doi>10.1577/H02-043</doi> <resource>http://www.tandfonline.com/doi/abs/10.1577/H02-043</resource> </doi_data> </journal_article> </journal> </crossref> </doi_record> </doi_records>

<?xml version = "1.0" encoding="UTF-8"?>

<query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <head>
      <email_address>hisham@atypon.com</email_address>
      <doi_batch_id>Sample multi resolve</doi_batch_id>
  </head>
  <body>
       <query key="mykey" expanded-results="true">
           <doi>10.1006/jmbi.2000.4282</doi>
       </query>
   </body>
</query_batch>

DOI-to-metadata XML Batch Query:

DOI-to-metadata queries can also be performed using XML, allowing use of control features available only with XML queries. See Querying with XML for details.

Sample XML query + show/hide {style=“margin-left: 40px; “}

<?xml version = "1.0" encoding="UTF-8"?>

<query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<head>

<email_address>support@crossref.org</email_address>

<doi_batch_id>Sample multi resolve</doi_batch_id>

</head>

<body>

<query key="mykey" expanded-results="true">

<doi>10.1006/jmbi.2000.4282</doi>

</query>

</body>

</query_batch>

DOIs with special characters

Mon, 01 Jan 0001 00:00:00 +0000

Building URLs for DOIs containing special characters

Some characters require special treatment in outbound DOI links.

Encode the pound (#) character using %23. For example, use:

http://dx.doi.org/10.1002/(SICI)1521-3951(199911)216:1<135::AID-PSSB135>3.0.CO;2-%23

instead of:

http://dx.doi.org/10.1002/(SICI)1521-3951(199911)216:1<135::AID-PSSB135>3.0.CO;2-#

Encode the left bracket or less than symbol (<) as \$lt; and the right bracket or greater than symbol (>) as >.
Do not encode the forward slash (/) character.

Establishing a DOI suffix pattern

DOIs, OpenURL, and link resolvers

Mon, 01 Jan 0001 00:00:00 +0000

DOIs, OpenURL, and link resolvers

For optimal integration with library linking systems, information providers are implementing the OpenURL standard. OpenURL is a mechanism for transporting metadata and identifiers describing a publication for the purpose of context-sensitive linking through a local link resolver.

A link resolver is a system for linking within an institutional context that can interpret incoming OpenURLs, take the local holdings and access privileges of that institution (usually a library) into account, and display links to appropriate resources. A link resolver allows the library to provide a range of library-configured links and services, including links to the full-text, a local catalogue to check print holdings, document delivery or ILL services, databases, search engines, and so on.

Why libraries need local link resolvers

DOIs point to the authoritative version of content on the publisher’s web site and to publisher-designated resources. Yet for the user working in an institutional context, it is often useful to be directed to other resources. For example, the institution may not subscribe to the electronic journal itself but may still be able to offer the user access to the desired article through an aggregated database or through print holdings. In addition, the library may want to provide a range of linking options beyond what is available at the publisher’s web site.

How the DOI System and OpenURL work together

The DOI and the OpenURL work together in several ways. First, the DOI directory itself—where link resolution occurs in the Crossref system—is OpenURL-enabled. This means that it can recognize a user with access to a local resolver. When such a user clicks a DOI, the Crossref system allows the DOI to be used as a key to pull the metadata needed to create the OpenURL targeting the local link resolver out of the Crossref database and redirects that DOI back to the user’s local resolver. Consequently, the institutional user clicking the DOI is directed to appropriate resources. By using the Crossref DOI system to identify their content, publishers in effect make their products OpenURL aware.

Localized linking via DOI redirection occurs in this sequence, as shown in the following illustration: + show/hide illustration

A library user clicks a DOI link within a link resolver-enabled resource.
A cookie on the user’s machine alerts the DOI proxy server to redirect this DOI to the local linking server.
The local linking server receives the metadata needed for local resolution either from the source of the link or from Crossref via OpenURL.

An OpenURL link that contains a DOI name is persistent in the same way a DOI name is. Publishers who use the Crossref DOI system to identify their content, in effect, make their products OpenURL-aware.

Using the Open URL Query Interface, Setting up your system for localized linking
For more information on OpenURL, see http://library.caltech.edu/openurl.

Deposit Harvester

Mon, 01 Jan 0001 00:00:00 +0000

Deposit Harvester

The Deposit Harvester allows members to retrieve metadata and DOIs deposited with Crossref. The metadata retrieved is in Crossref’€™s UNIXREF schema format, which delivers the exact metadata submitted in a deposit and includes any citations that have been deposited. Members (or their designated third parties) may only retrieve their own metadata.

The service uses the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) to deliver the metadata. The verbs Identify, ListMetadataFormats, ListSets, ListIdentifiers, ListRecords, and GetRecord are supported.

Ownership and retrieval restrictions

The Deposit Harvester will only retrieve metadata to the authorized owner. Metadata ownership is established by the DOI prefixes associated with a user’s system login. Most publishers have one prefix and one login, but some publishers may have multiple prefixes assigned to a single login. For example, Publisher A has been assigned system account “abcd”, which is associated with prefixes 10.xxxx, 10.yyyy, and 10.zzzz. Publisher A can retrieve metadata owned by prefixes 10.xxxx, 10.yyyy, and 10.zzzz using their ‘abcd’ login.

Ownership of DOIs and titles often moves from publisher to publisher, so a title owning prefix will not always match the prefix of the DOIs attached to the title. Retrieval restrictions are established by current owner, not original depositor. For example, Publisher B deposits a journal article DOI, 10.5555/jfo.33425. Ownership of the journal is transferred to Publisher A, who assigns it to prefix 10.xxxx.

Sets

The Deposit Harvester supports a hierarchy of sets. The hierarchy is in three parts: <work-type>:<prefix>:<publication-id>. For example, the set “J:10.12345:6789” will return metadata for a journal (J), with prefix “10.12345”, and publication id “6789”. The set “B” will return all book metadata. The set “S:10.12345” will return all the series metadata associated with the 10.12345 prefix.

The work-type designators are:

‘J’ for journals
‘B’ for books and book-like works (reports, conference proceedings, standards, dissertations)
’S’ for non-journal series and series-like works.

If no set is specified, the set “J” is used.

Sample requests:

ListSets: retrieve list of titles owned by the prefixes assigned to your system login:

http://oai.crossref.org/DepositHarvester?verb=ListSets&usr=&pwd=<password>

ListRecords

Retrieve data for a prefix:

http://oai.crossref.org/DepositHarvester?verb=ListRecords&metadataPrefix=cr_unixml&set=:<prefix>&usr=<username>&pwd=<password>

Retrieve data for a single title:

http://oai.crossref.org/DepositHarvester?verb=ListRecords&metadataPrefix=cr_unixml&set=:<prefix>:<title ID>&usr=<username>&pwd=<password>

GetRecord: retrieve data for a single DOI:

http://oai.crossref.org/DepositHarvester?verb=GetRecord&metadataPrefix=cr_unixml&identifier=info:doi/&usr=<username>&pwd=<password>

When using GetRecord, the <DOI> value should be URL encoded.

Identify: use to check the status of the Deposit Harvester (no login needed):

http://oai.crossref.org/DepositHarvester?verb=Identify

ListMetadataFormats: lists available metadata formats (currently UNIXREF)

http://oai.crossref.org/DepositHarvester?verb=ListMetadataFormats

Request parameters:

work-type:J for journals, B for book or conference proceeding titles, S for series

prefix: the owning prefix of the title being retrieved

title ID: the title identification number assigned by the Crossref system. Title IDs are included in the ListSets response described above.

username and password: system login for the prefix/title being retrieved

Results

Results conform to Crossref’s UNIXREF format and may contain the following root elements:

journal
book
conference
dissertation
report-paper
standard
sa_component
database

Resumption tokens

Some OAI-PMH requests are too big to be retrieved in a single transaction. If a given response contains a resumption token, the user must make an additional request to retrieve the rest of the data. You must provide the account name and password with both the initial request and subsequent resumption requests. A resumption without authentication details will fail.

Initial request:

http://oai.crossref.org/DepositHarvester?verb=ListRecords&metadataPrefix=cr_unixml&set=J:10.4102:83986&usr=&pwd=<password>

Request with resumption token:

http://oai.crossref.org/DepositHarvester?verb=ListRecords&metadataPrefix=cr_unixml&set=J:10.4102:83986&usr=&pwd=<password>&resumptionToken=01f7f30e-f692-4cc4-97b2-1eaf88b3f17f

See Using OAI-PMH for details.

Records will not be returned in a predictable sequence -€“ changes to the Data Harvester may affect how results are ordered.

Deposit basics

Mon, 01 Jan 0001 00:00:00 +0000

Deposit basics

Depositing metadata to Crossref involves the creation of XML according to our deposit schema. This XML is submitted to the Crossref System via public or machine interfaces. During the submission process, DOIs and metadata are added to the Crossref system, and DOIs are registered with the Handle resolver. Once deposited, DOIs may be resolved by prepending the DOI with http://dx.doi.org. DOIs (and metadata) may also be retrieved by querying once a deposit has been processed successfully.

Step-by-step

The basic process for depositing consists of these steps:

Create XML using the Crossref deposit schema (non-technical users may use the Web Deposit form).
Verify your XML: while not required, verifying XML prior to deposit helps prevent interruptions to your publication schedule.
Upload your XML: via a web interface or programatically (note: this step is not required for Web Deposit users)

The upload process is very basic and performs no data validation at the time of upload. The ‘Success’ acknowledgment you receive after submission step simply indicates that your file has been received.

Review your submission logs: After a deposit is processed, you receive an emailed submission log containing the result of your submission. Note that while many DOIs in a file may successfully get deposited, individual DOIs may fail. Submission logs must be examined, and any flagged problems should be corrected and the file(s) resubmitted.

Deposit content types, Best practice for depositing

Deposit content types

Mon, 01 Jan 0001 00:00:00 +0000

Deposit content types: what can be deposited?

Crossref enables DOI assignment for a variety of content types and at multiple levels:

Journals: DOIs may optionally be assigned to the journal itself, a specific volume or a specific issue. However, we strongly encourage the assignment of a DOI at the journal title level (journal title DOIs often use the ISSN as the suffix). DOIs should be assigned to all articles published within the journal and may be assigned to other content as well (e.g. book reviews, editorials etc.). Items that are part of an article which may benefit from having their own identifier can be registered as components and given a DOI unique from that of the article. These items include figures, tables or supporting data files.
Books: DOIs are always assigned at the book title level and frequently at the chapter level as well. Books may also be deposited as part of a series in which case the series is assigned a DOI unique from the DOI of any volume within the series. Book deposits should have an ISBN when available for each volume title and must have an ISSN for each series title.
Conference proceedings: Conference proceedings are quite similar to journals/articles with the major exception being the metadata includes information about the conference event as well as the proceedings title. Each paper within the proceedings is treated like a journal article.
Components: Components are parts of some other content type which are to be given their own DOI. They require a parent DOI which may be the DOI of an article, journal, book, chapter, standard or any other DOI. Components may be deposited along with their parent or they can be deposited by themselves in a separate XML file.
Dissertations and thesis: DOIs are assigned to each dissertation or thesis. DOIs are not assigned to an aggregation of this content type (e.g. if a collection of dissertations is published together it most likely would be deposited as a book).
Reports and working-papers: This content type resembles books in many ways with the major difference being an ISBN is not required. DOIs need not but are strongly encouraged to be assigned at the title level. Lower level “content-items” may also be given their own DOI (similar to chapters in a book). Reports/working-papers may be published as part of a series in which case the series title is given a unique DOI and must have an ISSN. Volumes published with a series must also have an ISBN.
Standards:Standards are assigned a DOI at the title level and may also have DOIs assigned to lower level “content-items”. Standards published as stand alone publications do not need an ISBN but like reports if they’re published in a series ISBNs and ISSNs are required. The metadata for standards differ primarily in the inclusion of additional designators along with the title which are commonly used when referring to a standard.
Database: Databases are another top level construct which can be assigned a DOI. Lower level items within a database, called datasets, are each given a unique DOI and any database/dataset DOI may include components. This content type has been used to address a number of situations that do not easily fall into the other categories. While originally intended for more traditional collections of data we have found this content type useful for allowing to DOIs to be assigned to a number of collections which might not be considered a ‘database’ but which defy easy classification into the other content type.

DOIs can be assigned to any object that is accessible online. Each DOI is assigned a primary URL during the deposit process which points to what we call the response page. DOI response pages must meet Crossref membership rules, which at a minimum requires display of the bibliographic data (article title, author, publication title, date of publication) and the DOI displayed as a URL.

Crossref deposit schema

Deposit schema

Mon, 01 Jan 0001 00:00:00 +0000

Crossref Deposit Schema

Depositing metadata with Crossref involves creating an XML file formatted according to our XSD schema. Versions 4.3.0 through 4.3.7 are currently being accepted for deposits. The most recent versions (4.3.6 and 4.3.7) are recommended. Initial DOI deposits must be made using the deposit schema. Sample deposit files are available here. Select metadata may be added to an existing deposit using the DOI resources schema.

Deposits for standards must use schema versions 4.3.6 and above.
In schema versions 4.3.4 and beyond, <depositor_name> replaces the <name> element.

Metadata deposits:

New: crossref4.3.7.xsd (crossref4.3.7.xsd | documentation)

support for linked clinical trials
supports journal deposits without ISSNs

crossref4.3.6.xsd (crossref4.3.6.xsd | documentation)

revised support for standards

****crossref4.3.5.xsd (crossref4.3.5.xsd | documentation)

includes support for relationships between DOIs (via relations.xsd)

Also supported:

crossref4.3.4.xsd (crossref4.3.4.xsd | documentation)
****crossref4.3.3.xsd (crossref4.3.3.xsd | documentation)
crossref4.3.2.xsd (crossref4.3.2.xsd | documentation)
crossref4.3.1.xsd (crossref4.3.1.xsd | documentation) has been released to support funding and deposit of ORCIDs.
Version 4.3.0 is still available: (crossref4.3.0.xsd | documentation)

Resource or citation-only deposits:

The DOI resources schema alleviates the need to include base metadata when adding supplemental metadata such as citations, Crossmark, and funding.

doi_resources4.3.5.xsd (doi_resources4.3.5.xsd | documentation) adds support for relationships between DOIs and other identifiers

Also supported:

doi_resources4.3.4.xsd (doi_resources4.3.4.xsd | documentation)
doi_resources4.3.2.xsd (doi_resources4.3.2.xsd | documentation)
doi_resources4.3.0.xsd (doi_resources4.3.0.xsd | documentation)

Depositing and distributing references

Mon, 01 Jan 0001 00:00:00 +0000

Depositing and distributing references

In addition to article metadata, Crossref members may also deposit reference lists. Reference deposit is optional, but required for cited-by linkingparticipants.

By default, references deposited for a DOI are only distributed to the current owner of the DOI or to OAI-PMH subscribers (when given permission by the current publisher). Crossref member publishers may also now elect to include deposited references in UNIXML query results as well as OAI-PMH results, making references publicly available. This feature is managed on a prefix basis. Contact support@crossref.org if you would like reference distribution enabled for your prefix(es). Reference distribution is encouraged for all members.

Depositing references

Mon, 01 Jan 0001 00:00:00 +0000

Depositing References

Reference-only deposits are really nothing more than the list of references in an article’s bibliography. Under Crossref’s normal linking service, members deposit an article’s metadata and then - in a separate process - query for the DOIs of the references. In order to do that querying, the references must be parsed or extracted from the article to enable construction of a Crossref query. Reference-only deposits simply combine the identity of the article (the DOI in the metadata deposit) with its list of references (the list of queries).

References can be deposited in two ways:

As part of a metadata deposit

Publishers currently supply their article metadata in an XML file formatted according to the Crossref deposit schema.

+ show/hide example or right-click to download sample XML

.... <doi_data> <doi>10.50505/test_20051229930</doi> <resource>http://www.crossref.org/</resource> </doi_data>  <citation_list>  <citation key="ref1"> <journal_title>Current Opinion in Oncology</journal_title> <author>Chauncey</author> <volume>13</volume> <first_page>21</first_page> <cYear>2001</cYear> </citation>  <citation key="ref2"> <doi>10.5555/small_md_0001</doi> </citation>

{style=“line-height: 22.100000381469727px;“}
<citation key=“ref=3”>
<unstructured_citation>Clow GD, McKay CP, Simmons Jr. GM, and Wharton RA, Jr. 1988. Climatological observations and predicted sublimation rates at Lake Hoare, Antarctica. Journal of Climate 1:715-728.</unstructured_citation>
</citation>
</citation_list> </journal_article> </journal> </body> </doi_batch>

As a resource-only deposit

Participating publishers who do not wish to modify their existing metadata deposit process may instead deposit the reference lists in a separate reference-only deposit transaction. A special resource-only schema (doi_resources4.3.4.xsd | documentation) has been developed which allows for the deposit of references for an article that already has a Crossref-registered DOI. This schema and the full metadata schema make use of same common ‘include’ file to describe the references for an article.

+ show/hide example or right-click to download sample XML

... <doi_citations>  <doi>10.5555/small_md_0001</doi> <citation_list>  <citation key="ref1"> <journal_title>Current Opinion in Oncology</journal_title> <author>Chauncey</author> <volume>13</volume> <first_page>21</first_page> <cYear>2001</cYear> </citation>  <citation key="ref2"> <doi>10.5555/small_md_0001</doi> </citation>
<!– ****** Unstructured references may be included if structured XML is not available ***** –>

<citation key="ref3"> <unstructured_citation>Clow GD, McKay CP, Simmons Jr. GM, and Wharton RA, Jr. 1988. Climatological observations and predicted sublimation rates at Lake Hoare, Antarctica. Journal of Climate 1:715-728.</unstructured_citation> </citation> </citation_list> </doi_citations> </body> </doi_batch>

In both approaches, an article’s references are described using the <citation_list> XML element. This element contains one or more citation> elements (which is also common to both of the above methods). The <citation> element contains the same fields needed in a normal Crossref query.

Depositing references to non Crossref DOIs

Current elements for citation deposits

The current elements for citation tagging are :

<issn>: ISSN of a series (print or electronic)
<journal_title>
<author>: first author of an article or other publication
<volume>: volume number (journal or book set)
<issue>: journal issue
<first_page>
<cYear>: year of publication
<article_title>: journal article, conference paper, or book chapter title
<isbn>
<series_title>: title of a book or conference series
<volume_title>: book or conference proceeding title
<edition_number>
<component_number>:the chapter, section, part, etc. number for a content item in a book.
<unstructured_citation>: citations for which no structured data is available. Crossref’s ability to process unstructured citations is limited (more info)
<doi>: include the DOI wherever possible

Review schema documentation for the <citation> element for more information.

The <citation> element is modeled after the <query> element found in the Crossref XML query schema.
Reference by default are not distributed with query results, but can be distributed with publisher consent.
References may be submitted using the Simple Text Query form. Usage limits are in place.

Depositing references to non Crossref DOIs

Mon, 01 Jan 0001 00:00:00 +0000

Overview {wrap=“”}

As part of our CitedBy service Crossref for a long time has accepted the deposit of references to items that also have Crossref assigned DOIs. This allows one Crossref member to build a CitedBy relationship to another member’s DOI (or another of their own DOIs). The owner of the Crossref DOI being cited can then use our APIs to retrieve the list of citing DOIs. The intention of this service is to process the items in the bibliography of an article or other manuscript and establish a CitedBy network between content that has been given a Crossref DOI.

Recognizing that relationships may exist other than those defined by the bibliography, we introduced the concept of typed relations between items where one participant in the relationship may or may not be defined by a Crossref DOI. This allows any Crossref member to claim a specific type of relationship between their content item and any other member’s content item or to an item that does not have a Crossref DOI, for example a Datacite DOI. See (help section on relations)

Combining these two features allows a Crossref member to deposit their DOIs and include citations to content that does not have a Crossref DOI.

Citing an object not represented by a Crossref DOI {wrap=“”}

A Crossref member may deposit in the reference list for their deposited item’s metadata (ex: journal article or book chapter) a reference to a non-Crossref DOI. This action creates a relation of type ‘cites’ between the Crossref item represented by the deposited DOI and the external item. The non Crossref DOI being cited must exist.

The citation deposit would look like this:

Here a Datacite DOI is being cited and the citation’s key is set to the value “ref3” (note: this must be unique within the set of citations for a given article). The resultant log for the deposit may look like this:

This example has 5 citations being deposited for the DOI 10.50505/doi_2006042312. The first two successfully resolved to an existing Crossref DOI. The third successfully resolved to a non Crossref DOI (in this case it is a Datacite DOI). The forth produced an error because the DOI being cited should be a Crossref DOI (based on the prefix) but it does not exist. The fifth produces an error because the external item (non Crossref) DOI also does not exist.

Once the deposit has been processed the following calls can be made to retrieve information about the generated ‘cites’ relation.

https://doi.crossref.org//getResolvedRefs?doi=10.50505/doi_2006042312&usr=creftest&pwd=***

This shows the matched citations for the deposited DOI. Note that only the three sucessfully resolved references are shown. The content type is unknown for the item represented by the Data Cite DOI.

https://doi.crossref.org/relations/find?doi=10.5167/UZH-29884

This shows that DOI 10.5167/UZH-29884 is the subject of a claim (as shown in the asClaimant:false section) by DOI 10.50505/doi_206042312 which claims to cite it. The description indicates that the relationship was created during the processing of citations for the 10.50505 DOI.

Why do this?

Creating citations and other types of relationships helps build a robust mapping between scholarly objects. Such a mapping advances information services that foster proper accreditation and improves the overall outcome of scholarly activities. Depositing this information enables Crossref to propagate it into the metadata stream that Crossref supplies to a growing number of recipients.

Depositing secondary URLs

Mon, 01 Jan 0001 00:00:00 +0000

Depositing secondary URLs

Content owners (or their agents) will continue to make deposits of DOIs, metadata and prime URL using the main Crossref metadata schema. Aside from unlocking multiple resolution DOIs, content owners need not do anything different when multiple resolution activity is occuring.

Secondary URLs are most often submitted as a resource deposit by a secondary depositor. The secondary URL deposit consists of the DOI being updated, the secondary URL (or URLs), and a label. No item-level metadata is required:

<doi_resources>

<doi>10.50505/mrtest</doi>

<collection property="list-based">

<item label="SECONDARY_X">

<resource>http://www.crossref.org/test1</resource>

</item>

</collection>

</doi_resources>

The label provided with the secondary URL associates the proper <resource> to the corresponding link item in the interim page template. The label(s) provided in the secondary deposit must match a label established in the interim page template. The *label* value is case-sensitive, the label must be a minimum of 6 characters (no spaces).

Right-click to download a sample secondary URL deposit.

Secondary URLs may also be provided in a primary metadata deposit (example).

Uploading secondary URLs

A secondary URL resource deposit must be uploaded with type ‘doDOICitUpload’ for HTTP POST (or ‘DOI Resources’ when using the system interface). The secondary depositor must have permissionto add URLs to the primary depositor’s DOIs.

Updating secondary URLs

A secondary depositor may update their URL by simply resending the XML file to Crossref with the modified value. The item*label*value and the depositor login must be consistent with the previous update.

Depositing translations

Mon, 01 Jan 0001 00:00:00 +0000

Assigning DOIs to translations

If the deposit metadata for the translation differs from the metadata for original language item, a distinct DOI may be assigned to the translation.

At least one of the following elements must be distinct: ISSN, ISBN, volume, issue, first page.
The original language title should be deposited in the translated article metadata in the <original_language_title> element.

Assigning separate DOIs to article translations is recommended but optional. Publishers wishing to assign one DOI to an article and its translations may do so. The DOI response page should contain links to translated versions of the article. This can be managed by the publisher web site or using Multiple Resolution.

Depositor report

Mon, 01 Jan 0001 00:00:00 +0000

Viewing a Depositor report

The Depositor Reports list all DOIs for a title on a publisher-by-publisher basis. Reports are available for Journals, Books, and Conference Proceedings.

To use these reports, click on a publisher name. A listing of that publisher’s titles will expand below the name. Clicking on any publication title will open a text file which list all DOIs for that title. + show/hide example

Selecting ’AACN Publishing’ reveals two titles

Initial view:

Name: name of the Crossref member as it appears in the system. Members with more than one prefix will appear multiple times
Journal/Book/Conf Proc count: number of journal, book, or conference proceeding titles associated with the Crossref member
Total DOIs: total number of Crossref DOIs deposited for the selected title
Field Report: details missing metadata fields for each publisher, select to view.

Expanded / member-specific view:

Name of each journal, book, or conference proceeding with DOI names deposited by the member.
# DOIs: Total number of DOIs registered for each journal, book, or conference proceeding deposited by the member.
Last crawl date: date of last crawler report (if available)

Select a journal, book, or conference proceeding title to retrieve a list of DOIs for the title (DOI), the owner prefix of the DOI (OWNER), the timestamp value for the DOI (DEPOSIT-TIMESTAMP) and the date the DOI was last updated (LAST-UPDATED). + show/hide example

DOI OWNER DEPOSIT-TIMESTAMP LAST-UPDATED

10.4037/ajcc200485 10.4037 200906250933 2009-06-25
10.4037/ajcc2009100 10.4037 200906250933 2009-06-25
10.4037/ajcc2009101 10.4037 200906250933 2009-06-25
10.4037/ajcc2009107 10.4037 200910161019 2009-10-16
10.4037/ajcc2009110 10.4037 20101103144353 2010-11-03
10.4037/ajcc2009114 10.4037 200906250933 2009-06-25
10.4037/ajcc2009121 10.4037 200906250933 2009-06-25
10.4037/ajcc2009131 10.4037 20100501000355 2010-05-01
10.4037/ajcc2009134 10.4037 200903061212 2009-03-06
10.4037/ajcc2009147 10.4037 200909221328 2009-09-22
10.4037/ajcc2009151 10.4037 200909221328 2009-09-22
10.4037/ajcc2009162 10.4037 200911021338 2009-11-02

The title detail report is access protected. The members area login is provided in your initial welcome email, or you can request the login from support@crossref.org

Title-level depositor report data may also be retrieved using format=doilistas described here
The Missing Metadata / Field report and Crawler reports can be accessed from the main deposit report page.

Deprecated query formats

Mon, 01 Jan 0001 00:00:00 +0000

Deprecated query formats

Crossref currently supports but does not recommend use of the following legacy formats:

XSD_XML
Piped Queries
Piped Queries: author / article title

XSD_XML

The XSD_XML format follows the Crossref query output schema. It provides basic metadata that has been processed by the Crossref system.

Processed vs. un-touched DOI metadata

When deposits are made to Crossref the metadata is subject to two parallel tracks of processing. One writes the data, untouched by any modification, to a database record associated with the DOI name. The other processes the metadata in a way that better supports the query engine operation. This processing may modify values by separating alpha and numeric characters. One key area of processing involves publication title and ISSNs. In order for the query engine to work effectively DOI names are grouped according to the publication to which they belong. This is done based on the publication title. Consequently the Crossref system has a limitation regarding which ISSNs are associated to a given title. The system takes the first print and first electronic ISSNs and binds them to the publication title. Subsequent ISSNs received with DOI names for this publication will be stored as ‘other ISSNs’ and will not be returned in the query results for any DOI belonging to this publication. These ISSN values are used to improve the query matching function but can be incorrect values when returned in query results. Crossref administrators are able to manually correct this when errors occur.

Examples:

The two examples below show data for the same DOI (10.1664/0028-7199(2004)112[0183:ANSOMK]2.0.CO;2). The XSD_XML example shows the effect of adding expanded-results=“true” to the query. In the UNIXREF example a partial list of citations for this article (its bibliography) is also shown.

this would only happen if the user making the query was also the publisher who owned the DOI, or if the publisher had enabled citation distribution. Citation lists are not currently given out by Crossref to all query users.

XSD_XML Format

Without expanded results: + show/hide example <?xml version = "1.0" encoding = "UTF-8"?>

<crossref_result version="2.0" xmlns="http://www.crossref.org/qrschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 http://www.crossref.org/qrschema/crossref_query_output2.0.xsd">
<query_result>
<head>
<doi_batch_id>1159209970476</doi_batch_id>
</head>
<body>
<query status="resolved">

<doi type="journal_article">10.1664/0028-7199(2004)112[0183:ANSOMK]2.0.CO;2</doi>
<issn type="print">00287199</issn>

<journal_title>Journal of the New York Entomological Society</journal_title>
<author>Tinerella</author>
<volume>112</volume>
<issue>2</issue>
<first_page>183</first_page>
<year>2004</year>
<publication_type>full_text</publication_type>
</query>
</body>
</query_result>
</crossref_result>
With expanded results: + show/hide example <crossref_result version="2.0" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 http://www.crossref.org/qrschema/crossref_query_output2.0.xsd">
<query_result>
<head>
<email_address>hisham@atypon.com</email_address>
<doi_batch_id>Sample multi resolve</doi_batch_id>
</head>
<body>
<query status="resolved" fl_count="0">

<doi type="journal_article">10.1664/0028-7199(2004)112[0183:ANSOMK]2.0.CO;2</doi>
<issn type="print">00287199</issn>
<issn type="electronic">19372361</issn>

<journal_title match="exact">Journal of the New York Entomological Society</journal_title>
<contributors>

<contributor first-author="true"> <given_name>Paul P.</given_name> <surname>Tinerella</surname> </contributor>

*** All other authors would be listed here if deposited by the publisher ****
</contributors>
<volume match="exact">112</volume>
<issue match="exact">2</issue>
<first_page match="exact">183</first_page>
<year match="exact">2004</year>
<publication_type>full_text</publication_type>
<article_title>

A NEW SPECIES OF MICRONECTA KIRKALDY (HETEROPTERA: CORIXIDAE: MICRONECTINAE) FROM WESTERN NEW GUINEA WITH A KEY TO MICRONECTA OF NEW GUINEA
</article_title>
</query>
</body>
</query_result>
</crossref_result>
with list-components set to true: + show/hide example

UNIXREF Format:

+ show/hide example

<doi_records xmlns="http://www.crossref.org/xschema/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> < doi_record> <crossref> <journal> <journal_metadata language="en"> <full_title>Journal of the New York Entomological Society</full_title> <abbrev_title>J New York Ent Soc</abbrev_title> <issn media_type="print">0028-7199</issn> </journal_metadata> <journal_issue> <publication_date media_type="print"> <year>2004</year> </publication_date> <journal_volume> <volume>112</volume> </journal_volume> <issue>2</issue> </journal_issue> <journal_article publication_type="full_text"> <titles> <title>A NEW SPECIES OF MICRONECTA KIRKALDY (HETEROPTERA: CORIXIDAE: MICRONECTINAE) FROM WESTERN NEW GUINEA WITH A KEY TO MICRONECTA OF NEW GUINEA</title> </titles> <contributors> <person_name sequence="first" contributor_role="author"> <given_name>Paul P.</given_name> <surname>Tinerella</surname> </person_name> <person_name sequence="additional" contributor_role="author"> <given_name>John T.</given_name> <surname>Polhemus</surname> </person_name> </contributors> <publication_date media_type="print"> <year>2004</year> </publication_date> <pages> <first_page>183</first_page> </pages> <publisher_item> <item_number item_number_type="sequence-number">0028-7199-112-2-183-51503</item_number> </publisher_item> <doi_data> <doi>10.1664/0028-7199(2004)112[0183:ANSOMK]2.0.CO;2</doi> <timestamp>200607170944480000</timestamp> <resource> http://www.bioone.org/perlserv/?request=get-abstract&doi=10.1664%2F0028-7199(2004)112%5B0183%3AANSOMK%5D2.0.CO%3B2 </resource> </doi_data> <citation_list> <citation key="I0028-7199-112-2-183-CHEN1"> <issn>0022-8850</issn> <journal_title>Univ. Kans. Sci. Bull</journal_title> <author>Chen</author> <volume>46</volume> <first_page>147</first_page> <cYear>1965</cYear> </citation> <citation key="I0028-7199-112-2-183-JANSSON1"> <issn>0785-8760</issn> <journal_title>Ann. Entomol. Fenn</journal_title> <author>Jansson</author> <volume>55</volume> <first_page>161</first_page> <cYear>1989</cYear> </citation> </citation_list> </journal_article> </journal> </crossref> </doi_record> </doi_records>

Piped queries

Content in Crossref is stored according to genre since variations exist in the structure of references to these different kinds of content. Consequently, piped queries come in two types: a 10 field query used to search journal or conference proceeding DOIs and a 12 field query used to search conference proceedings or book/reference DOI names.

Since conference proceedings often have metadata identical to journal articles but may have metadata similar to books both types of piped queries search against this genre.

A piped query *must* include either a starting page number, the author’s last name, or both. If a query contains neither field, the Crossref system will reject it.

Piped queries are written one per line. If more than one query is to be submitted in a single request they should be separated by a new line character (*n or %0A). The recommended maximum query batch size is 30 queries for synchronous, or interactive queries. For queries that are uploaded for asynchronous processing the maximum is limited by file size which should be kept under 1 Megabyte.

A piped query may also be used to perform a ‘reverse lookup’, aka DOI namequery, which retrieves metadata for a known DOI name.

Field descriptions:

* ISBN, ISBN/ISSN: Journal, book or conference proceedings ISBN or ISSN
* TITLE: journal title or abbreviation
* SER_TITLE: The serial title.
* VOL_TITLE: The book title.
* FIRST AUTHOR, AUTHOR/EDITOR: First Author surname.
* VOLUME: Book/Conference proceedings volume
* EDITION_NUMBER: Edition number for the book or conference proceeding (e.g. 3)
* PAGE: First page.
* YEAR: Year book or conference proceedings was published.
* COMPONENT_NUMBER: Chapter, section or part inside the book/conf. proceeding (e.g. Section 3)
* DOI: The DOI, left blank in the query
* RESOURCE_TYPE: The resource type (full_text, abstract_only or bibliographic_record)
* KEY: submitted buy the user to track queries (e.g. echoed back in the corresponding query result)

10 field query

The fields appear in this order:

Examples:

A query using an abbreviated journaltitle

Query: |Biol J Linn Soc|Hardy|64|2|239|1998||MyKey1|

Results: 00244066,10958312|Biological Journal of the Linnean Society|HARDY|64|2|239|1998|full_text|MyKey1|10.1006/bijl.1998.022
This query contains an ISSN instead of a title or abbreviated title:

00244066||Hardy|64||239|1998||MyKey2|
Here, only the title, author, starting page, and year are passed.

|Biol J Linn Soc|Hardy|||239|1998||MyKey1|
Here a several piped queries together:

|Trends Ecol Evol|Murcia|10||58|1995||k1|
|Urban Ecosyst|Jokimäki|3||21|1999||k2|
|Science|Maniatis|278||818|1997||k3|
|Annu Rev Immunol|Baeuerle|12||141|1994||k4|
|Proc Natl Acad Sci USA|Miagkov|95||13859|1998||k5|
|Lancet|Bonn|351||1710|1998||k6|
|N Engl J Med|Barnes|336||1066|1997||k7|

Results:

01695347|Trends in Ecology & Evolution|Murcia|10|2|58|1995|full_text|k1|10.1016/S0169-5347(00)88977-6
10838155,15731642|Urban Ecosystems|Jokim?ki|3|1|21|1999|full_text|k2|10.1023/A:1009505418327

00368075,10959203|Science|Maniatis|278|5339|818|1997|full_text|k3|10.1126/science.278.5339.818
|Annu Rev Immunol|Baeuerle|12||141|1994||k4|
00278424,10916490|Proceedings of the National Academy of Sciences|Miagkov|95|23|13859|1998|full_text|k5|10.1073/pnas.95.23.13859
01406736,1474547X|The Lancet|BONN|351|9117|1710|1998|full_text|k6|10.1016/S0140-6736(05)77753-9
00284793,15334406|New England Journal of Medicine|Barnes|336|15|1066|1997|full_text|k7|10.1056/NEJM199704103361506

The query with Key k4 did not match any DOI. In query ‘k5‘ the results contain two ISSNs, the first is for the print journal while the second is for the online edition. Notice the problem with the author name in ‘k2’. Here the special character in the query (small a with diaeresis) was not handled properly by the browser , whose default character set was UTF-8. XML queries and result formats are better suited to handle special characters.

12 field query

The fields appear in this order:

Several book queries shown together

Query:

|IEEE Press Series on Digital & Mobile Communication|Theory of Code Division Multiple Access Communication|Zigangirov|||137|2004|||| ||Physical Chemistry of Macromolecules|Sun|||267|2004|||| |Contributions to Nephrology|Nutritional and Acid-Base Aspects of Amino Acid Metabolism|Lardner|121||117|1997|||| |Methods in Enzymology|Carotenoids Part B Metabolism Genetics and Biosynthesis|LAKSHMAN|214||256|1993||||

Results:

0471457124,0471 0471457124,047165549X|IEEE Press Series on Digital & Mobile Communication|Theory of Code Division Multiple Access Communication|Zigangirov|||137|2004||full_text|k1|10.1002/047165549X.ch4
0471281387,0471623571||Physical Chemistry of Macromolecules|Sun|||267|2004||full_text|k2|10.1002/0471623571.ch12
3805564902|Contributions to Nephrology|Nutritional and Acid-Base Aspects of Amino Acid Metabolism|Lardner|121||117|1997||full_text|k3|10.1159/000059861
00766879,0121821153|Methods in Enzymology|Carotenoids Part B Metabolism Genetics and Biosynthesis|LAKSHMAN|214||256|1993||full_text|k4|10.1016/0076-6879(93)14070-Y

Author / article title piped query

The Crossref system supports a query mode where only article title and/or first author surname are required. These queries can be performed using the piped or XML formats.

Example: HTTP request with piped author/title query

The query type must be set to ‘a’ (for article/author), otherwise the request will be considered a malformed metadata query.

http://doi.crossref.org/servlet/query?usr=%3cusername%3e&pwd=%3cpassword%3e&**type=a**&format=unixref&qdata=Offline+Approaches|Gustafsson||key|

Example: piped bulk (asynchronous) query

These queries may also be submitted in bulk (asynchronous) using our batch upload feature. The uploaded file should be formatted with a header containing the email address to which the results will be sent followed by one query per line as shown here.:

H:email=youremail@publisher.org
Concluding remarks|Somiari||key1|
Off-line Approaches|Gustafsson||key2|
Monoclonal antibodies to feline sarcoma|Veronese||key3|

When performing a bulk upload using HTTP POST, the value of the HTTP parameter ‘operation’ must be doQueryUpload (please see Using HTTP to POST files).

Differences between the pilot and production MR

Mon, 01 Jan 0001 00:00:00 +0000

Differences between the pilot and production Multiple Resolution implementation

As of May 2008 the Crossref main system supports assigning more than one URL to a single DOI, a concept known as multiple resolution (MR). Prior to this time Crossref operated a pilot program which provided essentially the same service.

During Crossref’s pilot we explored two forms of multiple resolution, 1) an interim page solution 2) a pop-up menu system. Crossref’s production implementation of MR will only support #1, the interim page. The pop-up menu system exhibited obstacles which severely limited its adoption, primarily the need to alter the HTML constructs used when building DOI links which would need wide adoption which seems highly unlikely.

The main functional difference is that the production MR is based on permissions. Users are given permission to deposit only additional URLs, they are not permitted to change other metadata. The pilot worked by using the content owner’s login to submit MR data which left open the possibility of altering other (non MR) metadata.

In addition the pilot did not prevent the content owner from unintentionally removing MR data. In the pilot when the content owner updated the DOI’s metadata any interim page actions would be deactivated requiring the re-deposit of the MR data. In the production version of MR the content owner may still deactivate MR but must do so by specifically using the multi-resolution property which is not a data value typically addressed in a deposit.

The pilot version of multiple resolution has been discontinued. Pilot multiple resolution data was not saved within the Crossref system. In the production version a DOI query with format set to UNIXML will retrieve the current set of deposited MR data (by all permitted participants). DOIs that had been setup for MR using the pilot will continue to operate. However, we strongly recommend that users convert DOIs to the production MR version.

The template directives used in the pilot are different than those used by the production MR. If converting pilot version MR DOIs to production a new template must be created. It is possible to include both directives in one template which will allow older pilot version MR DOIs and production MR DOIs to use the same template (this is critical since templates are based on publication title ).

Elements

Mon, 01 Jan 0001 00:00:00 +0000

Required, Recommended, and Optional Elements

Content types:

Content type: Journal (documentation)

Required Elements

Journal: full_title, ISSN or title-level DOI
Issue issue, publication_date (year)
Article: titles, publication_date (year), doi_data

Issue elements are only required if a DOI is being deposited at the issue level. Article elements are likewise only required for article DOI deposits.

Recommended Elements

Journal: abbrev_title, doi_data, coden, journal_issue
Issue: publication_date (month, day), journal_volume, contributors, issue, doi_data
Article: contributors, ORCIDs, publication_date (day, month), pages (first_page, last_page), citation_list

Optional Elements

publisher_item
special_numbering
component_list

\^top

Content type: Book (documentation)

Required Elements

Series: titles, ISSN, volume, ISBN, publication_date (year), publisher (publisher_name)
Set: titles, ISBN, volume
Book: titles, publication_date (year), ISBN‡if no ISBN is available, use <noisbn> element, publisher
Chapter:doi_data

Recommended Elements

Series: doi_data,edition_number,contributors, coden, series_number, citation_list
Set: contributors, doi_data, edition_number, contributors, citation_list, doi_data
Book: contributors, ORCIDs, edition_number, doi_data, citation_list
Chapter: contributors, titles, pages, publication_date, citation_list

Optional Elements

publisher_item
part_number
component_number
component_list

\^top

Content type: Conference Proceedings (documentation)

Required Elements

Series: titles, ISSN, ISBN*required if volume title and volume number are present
Proceeding level:ISBN, proceedings_title, publisher, publication_date (year)
Conference paper: contributors, titles, doi_data

Recommended Elements

Series level: doi_data, contributors, coden, series_number
Conference level: volume, contributors, ORCIDs, event_metadata (conference_date, conference_location, conference_acronym, conference_theme, conference_sponsor, conference_number), proceedings_subject
Conference paper: publication_date, pages, citation_list

Optional Elements

publisher_item
component_list

\^top

Content type: Dissertation (documentation)

Required Elements
person_name
titles
approval_date
institution
doi_data

Recommended Elements

ISBN
degree
ORCID

Optional Elements

citation_list
component_list

\^top

Report-paper (documentation)

Required Elements

Series level: titles, ISSN
Report level: title, publication_date (year)

Recommended Elements

Series level: contributors, coden, series_number, volume, doi_data, edition_number, approval_date, publisher, institution, doi_data, citation_list
Report level: contributors, ORCIDs, edition_number, approval_date, ISBN, publisher, institution, citation_list

Optional Elements

publisher_item
contract_number

\^top

Standard (documentation)

Required Elements

Standard level: title, designator(s), approval_date, standard_body_name, standard_body_acronym
Item level: contributors, titles, component_number, publication_date (year), pages, publisher_item, doi_data

Recommended Elements

Standard level: contributors, edition_number, ISBN, institution, citation_list
Item level: citation_list

Optional Elements

publisher_item
content_item
component_list

\^top

Database (documentation)

Required Elements

Database level: titles
Dataset level: doi_data

Recommended Elements

Database level: contributors, description, database_date, publisher, institution, doi_data
Dataset level: contributors, titles, database_date, description, format, citation_list, component_list

Optional Elements

publisher_item
component_list

Errors and warning messages

Mon, 01 Jan 0001 00:00:00 +0000

Error and warning messages

DOIs with a “Warning” status have been deposited but may need extra attention. A status of “Failure” means that a DOI within a deposit, or an entire deposit, has failed. Failures may be the result of a system check or validation / processing error.

Warnings

Warning Meaning Solution

Added with conflict Two DOIs are in the system with the same metadata. This usually occurs when an article is published ahead of print such that no enumeration or page values are available. Review and resolve conflicts

Error messages: system checks

The Crossref system performs a number of checks that are beyond the scope of schema validation. These checks prevent the introduction of bad data to our system.

Error Message Meaning Solution

Record not processed because submitted version: xxxxxxx is less or equal to previously submitted version (DOI match) The timestamp in this update is dated before a previous update. The timestamp in the submission needs to be numerically greater than the timestamp in the previous submission. Review and edit the timestamp included in the deposit. Timestamps can be found in the Depositor report, by reviewing DOI history, or by retrieving DOI info-metadata.

User with ID: {0} cant submit into handle, please contact the Crossref admin The handle system username and password assigned to this prefix is incorrect in the Crossref system Contact support@crossref.org - include submission ID in your email

User not allowed to add records for prefix: {0} The Crossref account used does not allow deposits for this prefix Confirm that you are using the appropriate account and prefix then contact support@crossref.org. Include submission ID in your email.

All prefixes in a submission must match (DOI[{0}]) In a given XML file all DOIs being deposited must have the same prefix, regardless of ownership. Revise submission to include a single prefix (create multiple submissions if needed)

year: {0} in not a valid integer Year must be a string that converts to a valid 4 digit year Review and edit year

title “{title}” was previously deleted by a Crossref admin The title being deposited/updated previously existed in the system but was deleted Review your title and compare to previous deposits - if it is correct, contact support@crossref.org. Include submission ID in your email

user not allowed to add or update records for the title “{title}” The Crossref account used does not allow deposits for this title. Review title to confirm that you are using the appropriate account and prefix then contact support@crossref.org. Include submission ID in your email.

ISSN “12345678” has already been assigned to a different title/publisher/genre The ISSN, title, or ownership of your deposit does not match information in the system Refer to ISSN error troubleshooting guide

Error messages: common validation and processing errors

Error Message Meaning Solution

[error] :286:24:Invalid content starting with element {element name}‘. The content must match ‘((“http://www.crossref.org/schema/4.3.0": item_number) {0-3}, (“http://www.crossref.org/schema/4.3.0": identifier) {0-10}) This is an example of a parsing error being reported in the log file. Since this output comes directly from the Xerces parser the actual message will vary depending on the error. Review file at line / column indicated (in this example line 286 col. 24) edit and re-submit. Contact support@crossref.org for help if needed.

org.jdom.input.JDOMParseException: Error on line 312 of document file:///export/home/resin/journals/crossref/inprocess/395032106: The content of elements must consist of well-formed character data or markup. Indicates unacceptable markup in file Review the file as indicated, correct, and re-submit.

[fatal error] :1:1: Content is not allowed in prolog. Indicates characters (BOM) precede the XML - usually occurs when word processing programs are used Open file in a text / XML editor and remove characters (usually ï»¿)

java.io.UTFDataFormatException: invalid byte 1 of 1-byte > UTF-8 sequence (0x92) Indicates badly encoded character Locate and correct character - see Using Special Characters for more information

java.sql.SQLException: ORA-00001: unique constraint (ATYPON.NDX1_CIT_RELS) violated This error message occurs when 2 files containing the same DOIs are submitted simultaneously,or when a DOI is included twice in the same file. The system attempts to process both deposits - only one deposit will be successful. The unsuccessful deposit will generate this error. Review DOI history to make sure DOI is updated with correct metadata

java.lang.NullPointerException Most often this means a citation-only deposit or multiple resolution resource-only deposit has been uploaded as a metadata deposit (or vice-versa) Resubmit deposit as ‘DOI Resources’ (when using the Crossref System) or doDOICitUpload (HTTP transaction). If this does not apply to your deposit, contact support@crossref.org with details.

Submission version NULL is invalid Schema declaration is not correct Resubmit with correct schema declaration

Interpreting submission logs, Submission details, Viewing the Submission Administration report

Examples of DOI use

Mon, 01 Jan 0001 00:00:00 +0000

Examples of Crossref DOIs in use

DOI names appear in both print and online materials. DOI names are often included in tables of contents; header information for a digital item, such as an article; and citations, such as a footnote.

Crossref DOIs should always be displayed as a permanent URL, for example:

http://dx.doi.org/10.1115/1.2803632

DOI response page for journal article: + show/hide example

Response page (from http://dx.doi.org/10.1115/1.2803632)

DOI response page for journal article with journal DOI: + show/hide example

Response page (from http://dx.doi.org/10.3765/sp.5.1)

DOI response page for book chapter: + show/hide example

Response page (from http://dx.doi.org/10.1016/B978-0-12-394277-7.00001-4)

Crossref DOI Display Guidelines

FAQ: DOI display guidelines

Mon, 01 Jan 0001 00:00:00 +0000

FAQ: DOI display guidelines

Frequently asked questions about Crossref’s DOI Display Guidelines:

Should the new format be used on Crossref DOI response pages? Doing so results in a self-referencing link back to the page the reader is already on. Should we just display the DOI URL without making it a link?

The goal of the Crossref guidelines is to have the DOI used as the permanent link to the article. The Crossref DOI should always be displayed as part of the bibliographic information for the article—the permanent link to the article—so having it on response page as part of the bibliographical metadata is logical. Whenever the DOI is displayed it should be a link if possible. Self-referencing links often appear on the web. For example, clicking the logo or company name on a web site often reloads a home page. Blogs frequently include links to the page that a user is on. While it may be confusing at first for some users, the advantages, which include being able to use browser tools like the right-click to bookmark or copy a URL, and the ability for machines to read the DOI as a link, outweigh the drawbacks. When most scholarly publishers adapt this convention, users will quickly learn what the behavior of the link is.

Our Tables of Contents include multiple links to different versions of the content (PDF, HTML, and Abstract). Some publishers display the DOI on Tables of Contents, and some just hide the links under descriptive text. What should we do?

The guidelines recommend that Tables of Contents include a link to the response page in the URL format. Publishers may also choose to include other links directly to parts of the article.

Will adopting the new display guidelines have negative impact on a publisher’s citations in Thomson’s Web of Science?

No, the new format will have no effect on citation rankings.

Should we use the URL format in print and PDF as well as on HTML pages?

Yes, it would be preferable to display the DOI as a link whenever feasible. Doing so will help users to understand what to do with the DOI (click on the link or copy it), will help machines properly render and process the link (for example on a mobile reading device), and will provide a consistent experience for users. Publishers will need to weigh these advantages against the costs (for example, in using additional space for DOIs, or in possibly re-rendering older PDFs). For these reasons, the guidelines are recommendations, not requirements.

Should we continue to put the DOI behind linking text in our references, or should we display reference links using the new guidelines?

The guidelines include recommended options for reference linking, which include using the URL format, using a text link, or using a new Crossref linking graphic.

FAQ: General

Mon, 01 Jan 0001 00:00:00 +0000

Frequently Asked Questions

Considerations for DSpace repositories

Crossref encourages organizations which operate institutional repositories to assign DOIs to their original non-duplicative works. There are a few simple guidelines when the repository is a DSpace based system (http://www.dspace.org). DSpace and the DOI both utilize the Handle system for identifiers. When a DSpace repository is configured it must be registered with CNRI (http://www.cnri.reston.va.us/) who provides the repository operator with a Handle prefix (typically a sequence of numbers). This is not a DOI prefix (also a sequence of numbers which begin with “10.”).

In order to assign DOIs to DSpace items the repository must join Crossref and be given a DOI prefix. Subsequently each item for which a DOI is desired is deposited with Crossref using the Crossref deposit schema. The DOI is best constructed as shown here:

THE-DOI = DOI-prefix / DSpace-prefix / Dspace-suffix Example: 10.1575/1912/1099

The URL assigned to the DOI should use the form http://hdl.handle.net/DSpace-prefix/DSpace-suffix

Example: http://hdl.handle.net/1912/109 Referring to this item in print: doi:THE-DOI. A URL to item: http://dx.doi.org/THE-DOI

Crossref title records and ISSNs

When DOIs are deposited, the Crossref system must assign the DOI to an internal title record. This is necessary to support query processing which is heavily dependent on matching query fields to a publication. Upon deposit, the XML publication title is used to determine if Crossref already has a record for the publication. If needed a new title record is created, and then the DOIs in the deposit are assigned to that title. Title processing is a very simple ‘string’ compare thus an XML title using ampersand (&) would be considered unique from one using the word “and”. ISSNs are also dealt with in a simple manner. Once the system has determined the internal title record to use, the ISSNs are simply associated with that record. If the same ISSN is deposited with different versions of a title, all versions will end up having that ISSN.

Generally this is not a problem for the query match processing since the evaluation rules for a query are much more sophisticated and can overcome any confusion caused by such a condition. Further, the effected titles (e.g. the ‘&’ Vs ‘and’) are typically related or are really the same publication.

The need to do this results from a scale problem. By tracking titles as records the Crossref system has 14,000 or so items to compare when starting to match a query. If the publication title of each DOI were tracked and matched against on an individual basis the query matcher would have to start with over 22 million items.

Since mid 2002 when the system was deployed this situation has had the following consequence. The ISSNs returned in a query result have been the ones that the title record holds and not (necessarily) the ones deposited with the DOI. Compounding the problem is the way the system saves ISSNs against a given title record. For a new title record the system saves the first print and electronic ISSNs it is given as ‘THE’ print and electronic ISSNs for that title. Subsequent ISSNs are saved as additional values and are primarily used to help the matching process. These first ISSNs are what typically gets returned in the metadata for all queries.

In early 2006 we introduced a new query result format that solves this problem (format=unixref). Any query (XML or piped) that requests this format will be returned the exact data sent in by the publisher for that DOI. The first query shown below returns the ISSN 0163-1829 while the second returns 1098-0121. This results from the fact that the first ISSN is for an earlier version of this journal which has a different sub-title than the second ISSN. However, due to the nature of the deposits the Crossref system has only created one internal title record for this publication.

http://doi.crossref.org/servlet/query?usr=&pwd=<pwd>&type=q&format=xsd_xml&qdata=|Physical+Review+B| Bibikov|73|13|132402|2006|||

http://doi.crossref.org/servlet/query?usr=&pwd=<pwd>&type=q&format=unixref&qdata=|Physical+Review+B| Bibikov|73|13|132402|2006|||

What can a DOI be assigned to?

Crossref enables DOI assigment for the following content types:

Journals/working papers: journal title, volume, issue and article
Books: book series, title, chapter/section/entry
Conference proceedings: multi-volume title, title, paper
Components: sub-items of journal articles, book chapters/entries and conference papers including figures, tables, graphs and supplemental data.
Reports
Standards
Dissertations
Databases and datasets

Details are available here.

Depositing “As-Crawled” URLs to support metadata distribution to search engines.

Information on including as-crawled URLs is available here.

DOI Ownership transfer

Once a DOI is assigned to a piece of content it should remain unchanged and only one DOI should exist for a given piece of content. When ownership of content changes from one publisher to another (at the moment this is most commonly a journal changing ownership), it is necessary to transfer the ownership of the DOIs. Typically, a Crossref account can only be used to create/modify DOIs that have the same prefix as is associated with the user’s account. The ownership transfer modifies this relationship so that a specific group of DOIs are marked as belonging to a prefix other than the prefix in the DOI. It is important to note that the DOI itself is not modified at all in this process.

After a transfer occurs it is no longer possible to perfectly know who publishes a given journal simply by looking at the DOI’s prefix. But, this is fine since the DOI is intended to be an opaque identifier.

In addition, the ownership transfer process allows us to assign a new URL to the DOI redirecting it to the acquiring publisher’s Web site. This shortcut is provided since the acquiring publisher may not always have the original XML for these transferred DOIs and therefore would be unable to easily perform an update.

Please see the full details on Crossref’s DOI Ownership Transfer Policies and how to go about initiating a transfer.

Dealing with conflicts

Conflicts occur when two or more DOIs are deposited with Crossref having the same exact metadata. The fields that must match exactly are:

Omitting one or more fields in a deposit increases the chance of a conflict. Review Resolving Conflicts for information on how to handle conflicts.

Deleting a DOI

DOIs are supposed to be persistent and are therefore very difficult to delete. In fact the Crossref system has no “delete a DOI” function. Contact support@crossref.org if you are not able to maintain a DOI or have assigned a DOI to an item by mistake.

Special characters in deposits and queries

Special characters are those that are not part of the ASCII or ISO 8859-1 (Latin-1) character sets. ASCII and Latin-1 characters can be represented in one octet (byte) of information and are displayed properly in almost all editors and viewers on most computer systems.

More information on using special characters is available here.

Resolving problems with a DOI

Issues will either result from depositing DOIs, querying for DOIs or following links built with DOIs. Each represent a step in the life-cycle of a DOI and the systems involved in each step are unique. Generally, solutions are not very complicated, there is just a bit of detective work required to figure things out. IF you are not able to solve your problems using the help documentation, contact support@crossref.org. Please provide as much information about the problem as you can. Of particular importance are the submission IDs for deposits and the location of bad DOI links.

Using parameter passing

Parameter passing is a feature that allows data placed on an outbound DOI link to be passed along to the target publisher. More information on parameter passing is available here.

Using Stored Queries (aka. Query Match Alerts)

More information on storing queries for future matches is available here.

Face Markup

Mon, 01 Jan 0001 00:00:00 +0000

Face markup

The Crossref schema supports minimal face markup in order to avoid ambiguity in certain disciplines (e.g. Genetics, where the same text may be a gene (when italicized) or a protein (when not italicized).

Face markup that appears in the title, subtitle, original_language_title, and unstructured_citation elements should be retained when depositing metadata. Face markup in other elements (e.g. small caps in author names) must be dropped. Face markup support includes bold (b), italic (i), underline (u), over-line (ovl), superscript (sup), subscript (sub), small caps (scp), and typewriter text (tt).

Examples where inclusion of face markup is especially important include:

Italic in titles for terms such as species names or genes
Super and subscript in titles as part of chemical names (e.g. H20)
Super and subscript in simple inline mathematics (e.g. x2 + y2 = z2)

The schema supports nested face markup (e.g. “This text is bold and italic”), which would be tagged as:

This text is <b><i>bold and italic</i></b>

Correspondingly, super and subscript may be nested for correct representation of xyz. This expression should be tagged as:

x<sup>y<sup>z</sup></sup>

As of schema version 4.3.2, Crossref supports MathML markup in the title elements.

Forcing prime/alias

Mon, 01 Jan 0001 00:00:00 +0000

Forcing prime/alias

Publishers can force a DOI to be an alias of another DOI if the DOIs are not in conflict. To force an alias between two DOIs, create a text file as described below and upload to the Crossref System:

Create the .txt file with tab-separated pairs of DOIs as follows:

H:email=youremail@address.com;op=force_alias;delim=tab
10.xxxx/primary1 10.xxxx/alias1
10.xxxx/primary2 10.xxxx/alias2
10.xxxx/primary3 10.xxxx/alias3

Access the Crossref system.
Click the Submissions tab.
Click the Upload tab, if necessary.
Locate and select the metadata file.
Select Live.
Select Conflict Management.
Click Upload.

Supplying op=unalias allows you to unalias previously forced aliases.
Extreme care MUST be taken when using this feature. Normally two DOIs are put into a prime/alias pair when their metadata is the same and a conflict is created. In this case a metadata query will find both DOIs but because of the pairing will know to return the prime DOI.
With FORCED prime/alias pairs metadata queries using either DOI’s metadata will still work. So, if a pair has very different metadata then two very different metadata queries will return the prime DOI (and its metadata). This will likely appear as a false positive to the query caller.

Funder Registry

Mon, 01 Jan 0001 00:00:00 +0000

The Open Funder Registry

The Open Funder Registry provides a common taxonomy of over 10,000 international funding organization names together with unique IDs for each. Publishers should use the Registry to normalize collection of funding bodies from authors at the time of submission, and to deposit funding agency names (funder_name) and IDs (funder_identifier) with Crossref. For more information on depositing funding data see the main funding data help page.

The list is available to download as an RDF file, and is freely available under a CC0 license waiver.

DOWNLOAD 4.2 MB (RDF)

To the extent possible under law, Crossref has waived all copyright and related or neighboring rights to the Open Funder Registry.

Additional Options {xmlns:dct=“http://purl.org/dc/terms/"}

Download a CSV file of the funder names and identifiers in the Funder Registry.

Download a list of funders inJSON format.

Registry Updates {.morehelp}

How can I tell when the Registry was last updated?

The Funder Registry download links provided by Crossref allow HEAD requests; HTTP requests that will only return HTTP headers, rather than the whole registry file. HEAD requests can be used to retrieve a “last modified” date for the registry files. Below is an example of making a HEAD request to the Registry DOI. First a request is made to get the redirect location of the DOI, and then a second HEAD request is made to determine the last modified time of the registry file:

* curl -i -X HEAD http://dx.doi.org/10.13039/fundref_registry

* HTTP/1.1 303 See Other Server: Apache-Coyote/1.1

* Vary: Accept

* Location: http://www.crossref.org/docs/fundref/fundref_registry.rdf

* Expires: Wed, 03 Jul 2013 17:40:13 GMT

* Content-Type: text/html;charset=utf-8

* Content-Length: 200

* Date: Wed, 03 Jul 2013 08:45:50 GMT

Now follow the location redirect and make another HEAD request to find the last modified date of the registry:

* curl -i -X HEAD http://www.crossref.org/docs/fundref/fundref_registry.rdf

* HTTP/1.1 200 OK Server: Apache-Coyote/1.1

* Accept-Ranges: bytes

* ETag: W/“4252782-1372700920000”

* Last-Modified: Mon, 01 Jul 2013 17:48:40 GMT

* Content-Type: application/rdf+xml

* Content-Length: 4252782

* Date: Wed, 03 Jul 2013 08:45:59 GMT

* Connection: close

Here we can see that the registry was “Last-Modified” on 1st July 2013. This can be checked against a timestamp we may have previously recorded when downloading the registry. If the timestamp is more recent than the one we have recorded, or this is the first time we are downloading the registry, we would go ahead and make a normal GET request to download the registry file:

* curl -i -X GET http://www.crossref.org/docs/fundref/fundref_registry.rdf

* An alternative - using HTTP ETags

Funder Registry files also support ETags, which provide an alternative update check mechanism (also HTTP based.) See http://en.wikipedia.org/wiki/HTTP_ETag for more information.

How often should I check for updates?

We expect the Registry to be updated every couple of months, but you may wish to make HEAD requests to check for updates more frequently to ensure timely updates. Making a HEAD request once a day would be reasonable.

Do I need to retrieve the Open Funder Registry using its DOI?

We recommend that anyone wishing to download the Registry does so using its DOI. Crossref may change the underlying location of the registry download but the registry DOI, like any other DOI, will always redirect to the correct location.

This is particularly important for packaged software products where it would be difficult to change the registry download URL.

Funding data deposits

Mon, 01 Jan 0001 00:00:00 +0000

Funding Data XML Deposits

Funding metadata can be deposited with Crossref in two ways.

1) As part of the full set of metadata for an article.

2) In a stand-alone deposit where just the funding metadata is provided.

Please also read the detailed rules regarding funding metadata.

Stand-alone deposits:

Stand alone deposits are intended as a convience for depositing funding data to existing DOIs without having to repeat the existing metadata. The deposit XML file contains just the DOI of the article and the specific FundRef data.

If the DOI currently has any funding data it will be replaced by the stand-alone deposited data.

If the DOI currently has any Crossmark data, the stand-alone deposited funding data will be inserted within the existing (previously deposited) Crossmark data.

When uploading stand-alone deposits to Crossref using the HTTP POST API the operation must be doDOICitUpload.

When uploading using the system interface the file type must be DOI References/Resources

Full Metadata deposits:

Funding data may be deposited as part of a normal ‘full’ metadata XML deposit for a DOI.

Funding data via the API

Mon, 01 Jan 0001 00:00:00 +0000

Funding data via the API

Funding data can be accessed via the Crossref REST API. The API is openly available and there is no requirement to register or be a Crossref member.

Useful Queries {.morehelp}

All funders listed in the Open Funder Registry: http://api.crossref.org/funders
Find the funder ID for a specific funding body: http://api.crossref.org/funders?query={name}. E.g. http://api.crossref.org/funders?query=wellcome
List of DOIs associated with a specific funder: http://api.crossref.org/funders/{funder ID}/works. E.g. http://api.crossref.org/funders/100004440/works
Metatadata for DOIs that cite a specific award/grant number: http://api.crossref.org/works?filter=award.number:{grant number}. E.g. http://api.crossref.org/works?filter=award.number:CBET-0756451

See the REST API documentationfor detailed instructions on constructing further API queries.

Funder IDs are DOIs that share a common prefix. For the purposes of querying the API, only the long number at the end of the DOI (the suffix) should be used.

{style=“line-height: 19px; “}

Getting Started with Crossref

Mon, 01 Jan 0001 00:00:00 +0000

Getting started

Organizations participate in Crossref by joining under one of these three categories:

Member: a publisher or content owner who will be depositing DOIs with metadata
Library: a no-fee account for querying the Crossref system primarily used to support a local linking service
Affiliate: an organization (commercial or non-profit) which will be querying the Crossref system, using Crossref bulk metadata or acting as an agent for member publishers.

To see who is currently participating in Crossref please see:

Publishers & Societies: current publishers and societies that participate in Crossref.
Crossref Voting Members: a listing of all voting members.
Libraries: list of library members
Crossref Affiliates: organizations that are affiliates or agents

Qualifications for membership

Publishers International Linking Association, Inc. (PILA) is a not-for-profit membership organization. PILA runs the Crossref service, enabling links to and from online scholarly content. According to the PILA bylaws, membership is open to any organization engaged in the business of publishing original scholarly materials.

The following conditions must also be met:

The organization applying for membership must publish primary scholarly content that is available online in full text.
The organization must submit metadata, as defined by PILA, for substantially all its content that is online in full text.
In an organization with multiple divisions, the largest legal entity is considered the PILA member and all the divisions are subject to the terms of the PILA Membership Agreement.
To ensure fairness in reviewing candidates for membership, prospective members must supply information about the content they intend to deposit.

Only publishers who pay an annual membership fee and own the content represented by Crossref’s metadata are considered members who are entitled to vote for Crossref’s board of directors. Publishers may participate in Crossref without actually being a member themselves if they are represented by a Sponsoring Member.

Go-Live report

Mon, 01 Jan 0001 00:00:00 +0000

Go-Live report

The Go-Live report displays information about Crossref members and their activity on the Crossref site. In particular, the Go-Live report displays the following information:

Summary data: for the number of prefixes, members, and submissions over time
Name: Full name of the Crossref member
Prefix: Member’s Crossref-assigned DOI prefix
Date Joined: Date the member joined Crossref
Date of Last Deposit: Date of the member’s most recent deposit
Date of Last Query: Date of the member’s most recent query
Reference Links Live: indicates if member is linking references

Guidelines, Procedures, and Resources

Mon, 01 Jan 0001 00:00:00 +0000

Guidelines, Procedures, and Resources

Crossref Guidelines

Crossref DOI Guidelines - This document provides basic information about DOI syntax and use.
Guidelines for Standard Citations in Author Postings (pdf) 32KB - These guidelines outline Best practice for linking from an author posting of a postprint or preprint work within a repository to the related definitive publication. Crossref recommends that publishers communicate these guidelines to their authors and to Institutional Repositories.
Crossref Glossary - This glossary defines standard terms used in the description of published works, unpublished works, posted works, and versions. Comments and feedback on the Glossary are welcome - please email irc@crossref.org.
DOIs in Citation Export Services Guidelines (pdf) 21KB - This document guides publishers on how to integrate DOIs into their “Download Citation”/“Export References” services.
Metadata Guidelines
- These guidelines outline Best practice in publisher submission of metadata to Crossref, in order to enhance the quality of Crossref’s metadata and our ability to provide various services.

Best practice

Policies and Procedures

Groups and mailing lists

Support forum: announcements regarding system status or changes are posted in the Announcements forum (public). TWG Discussion(requires support login) replaces the TWG mailing list. Intended topics include technical matters related to Crossref’s services, DOI issues and Crossref system operation.

The Technical Working Group has been dissolved but the mailing list archives are still available.

Home

Mon, 01 Jan 0001 00:00:00 +0000

Welcome to Crossref Help {.search}

Browse the table of contents to the left for an overview of Crossref functions, or search our help documentation using the box above.

Popular Help & FAQs

New Topics

Getting Started

Popular Topics

Non-help links

Can’t find an answer? {.morehelp}

For technical support,
email support@crossref.org or open a support ticket.

Contact member@crossref.org for general inquiries and membership questions.

How Crossref works

Mon, 01 Jan 0001 00:00:00 +0000

How Crossref works

Crossref enables linking in scholarly content on a cross-publisher basis by providing two basic services:

DOI deposit and registration: Crossref registers DOI names and URLs in a central DOI directory (developed and maintained by the International DOI Foundation) on behalf of publisher members. The directory works by looking up the current URL for the specific DOI and sending the end user to that location. When a publisher changes the location of the content they need to update the URL in only one place: with Crossref. If the item moves to a new location, the URL link seen by users will still work, thereby establishing a permanent link. All Crossref DOIs must resolve to a valid response page.

For each content item deposited with Crossref, the publisher creates a unique DOI name by appending a suffix of their choosing to the prefix they’ve been assigned by Crossref . The publisher also creates an XML file which associates citation metadata with the DOI. The publisher then submits (uploads) the file to the Crossref system.

The metadata associated with a DOI can include:
- Basic bibliographic values including all authors, volume, issue, page number or article number, article title
- The references being cited within the item
- A list of figures, tables, images or other parts of the item (we call these components) which may benefit from having their own DOI for linking.
DOI lookup service:Crossref’s query interfaces allow users (including publishers, libraries, researchers, authors or the public) who know some amount of information about an item to retrieve a DOI and create persistent links. Users submit queries to Crossref which include as much metadata as they have (e.g. journal title, author, article title) and Crossref looks for the corresponding DOI and returns it to the user.

Although most transactions with Crossref are made by automated systems we have put in place several services designed for use by people. For smaller publishers who have limited technical resources or for end users like authors, researchers and librarians these services are intended for low volume activity. For detailed instructions on these services please see L ook up a Crossref DOI.

How it fits together

Using a DOI prefix assigned by Crossref, publishers create DOIs for content items. A publisher must also construct an XML file and upload to the Crossref system. When content is published online, the DOI name and metadata should be deposited with Crossref as soon as possible (within 24 hours is preferable).
Members also query Crossref to retrieve DOI matches (when available) for citations in the reference list for journal articles deposited with Crossref.
Members then use the DOI names retrieved from Crossref to create persistent outbound links to other members’ content.
An end user reading the content on-line finds a DOI based link and clicks on it.
The user’s browser first goes to the DOI central registry to retrieve the actual URL of the item.
The user’s browser is redirected to the DOI response page URL registered by the publisher.

Crossref provides initiatives and tools that supplement our core DOI registration and linking services, see Crossref Services.

How depositing works

Mon, 01 Jan 0001 00:00:00 +0000

How depositing works

Depositing references

How do Crossref DOIs work?

Mon, 01 Jan 0001 00:00:00 +0000

How do Crossref DOIs work?

A DOI link consists of two parts: the DOI directory URL (http://dx.doi.org/), and the DOI itself. When combined with dx.doi.org, the DOI is made into a link. When you click on a DOI link you are directed to the URL registered for the DOI.

For example:

http:/dx.doi.org/10.1006/jmbi.1995.0238

URLs in the DOI directory are updated when an item changes location, ensuring persistence. The DOI System and directory is managed by the International DOI Foundation.

Crossref DOIs

In addition to creating durable links, Crossref DOIs reliably identify content. If you follow a Crossref DOI to an article you’re assured that the page you view is the publisher maintained version of the article.

Crossref members deposit DOIs by submitting XML containing citation metadata and DOIs to the Crossref system. Crossref stores the metadata in our lookup service, and registers the DOI and URL in the central DOI directory. As a result, citation metadata is associated with all Crossref DOIs, making them retrievable via Crossref lookup services. This allows Crossref DOIs to be widely distributed, and supports collaborative reference linking between Crossref members. See How Crossref works for details.

How querying works

Mon, 01 Jan 0001 00:00:00 +0000

How querying works

Querying is the process of retrieving data from Crossref. There are two basic query modes:

Metadata query: you know the bibliographic data and wish to retrieve the DOI for the item
DOI query: you have a DOI and would like to retrieve associated metadata

The majority of query transactions occur automatically by users who build systems that make simple HTTP GET requests to our server. XML query files may also be submitted by HTTP POST or via the Crossref system web interface. Bulk query options are also available.

Crossref provides web-based query forms which are useful for individual authors or researchers looking to find a specific article, or by a member’s technical staff when trying to investigate a particular problem.

Query processes and options are described in detail in Queries & retrieving metadata

How to query

Mon, 01 Jan 0001 00:00:00 +0000

How to query

Most queries are submitted to Crossref via machine interfaces (some user-friendly interfacesare also available). Queries may be submitted via HTTPS POST or GET or (in small batches) through the system interface. Most queries are formatted as XML. XML queries allow significant control over the matching process Transactions are performed using HTTP GET or POST (batch queries).

The following is an example of a journal XML query: + show/hide

<?xml version="1.0"?>

<query_batch version="2.0" xsi:schemaLocation="http://www.crossref.org/qschema/2.0 http://www.crossref.org/qschema/crossref_query_input2.0.xsd" xmlns="http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<head>

<email_address>support@crossref.org</email_address>

<doi_batch_id>ABC_123_fff</doi_batch_id>

</head>

<body>

<query key="1178517" enable-multiple-hits="false" forward-match="false">

<issn match="optional">15360075<issn

<journal_title match="exact">American Journal of Bioethics</journal_title>

<author match="fuzzy" search-all-authors="false">Agich</author>

<volume match="fuzzy">1</volume>

<issue>1</issue>

<first_page>50</first_page>

<year>2001</year>

<article_title>The Salience of Narrative for Bioethics</article_title>

</query>

</body>

</query_batch>

HTTP queries

This process is described in detail in Using HTTPS to Query. Some rules of thumb:

Synchronous queries using HTTP GET should be limited to less than 5-10 queries per request
The response time for an HTTP GET query with one query in the request is generally under 1 second

Batch queries

Crossref supports a batch upload feature to accomodate large query volumes. Query files are uploaded to the Crossref system where they will wait in a queue for processing (similar to the deposit process). Files can contain either metadata formatted using our query input schema (schema | documentation) or DOI queries (but not a mix). Uploaded query files should be less than 150KBytes in size.

When the queries are processed, the results are emailed to the address supplied in the query XML. Users may request that their Crossref account be configured so that the email results notice contains a link to the result file which would subsequently be downloaded by the user. This avoids problems associated with large email files.

Query results

You may request the system to return query results in a number of formats. See Query Results for more information.

User-friendly query tools are also available.

ISSN errors

Mon, 01 Jan 0001 00:00:00 +0000

Common ISSN and ISBN Errors

Crossref has implement some title, ISSN, and ISBN checks to prevent title duplication and errors. The title/ISSN/ISBN combination submitted in a deposit must match the title/ISSN/ISBN combination in the Crossref database. Title/ISSN/ISBN combinations are extracted from the first deposit of a title, and can only be edited by Crossref staff.

Error: ISSN “{ISSN}” has already been assigned to a different title/publisher/genre

This error indicates the ISSN and/or title in your deposit does not match data in our system, or the title is owned by another publisher. Possible causes:

Title and ISSN in deposit do not match title associated with ISSN in the system
Title is owned by another publisher
DOI is owned by another publisher (if DOI is being updated)

+ show/hide solution

If you receive this error, check your deposit for the following:

ISSN and Title should match ISSN and Title in the Crossref system. To verify:
1. search by ISSN for your title in the Browsable Title List
2. compare the title(s) found to the title in your deposit.
3. if the titles do not match, correct the title or ISSN in your deposit or ask support@crossref.org to change your title in the system.
Verify system ownership - all titles in the system are locked to a single prefix. To verify the title being deposited is owned by the correct publisher:
1. search by ISSN for your title in the Browsable Title List
2. verify you are the publisher listed under ‘publisher’
  - if more than one publisher is listed, contact support@crossref.org
  - if you deposit under multiple prefixes andyou are not sure which prefix currently owns the title, contact support@crossref.org
  - if a different publisher is listed, verify that:
    - you are the correct publisher for this journal
    - you have notified Crossref of any title transfers. If you have not, please review Transferring DOI ownership.

If you are still not able to identify why your deposit was rejected, contact support@crossref.org with your submission information.

Error: ISSN “{ISSN}” has already been assigned to a different publisher {publisher name}({publisher prefix}) or ISBN “{ISBN}” has already been assigned to a different publisher {publisher name}({publisher prefix})

This error indicates that the title you are depositing is owned by another publisher/prefix. If you are the correct publisher for the title being deposited, verify that you have followed the title ownership procedures described in Transferring DOI ownership. If you have followed transfer procedures. contact support@crossref.org.

Error: ISSN “{ISSN}” is invalid

This error indicates that the ISSN provided in the deposit is not valid. All ISSNs must have a valid check digit as described here. This validation prevents transcription errors, which are common. If your deposit failes because of this error:

Carefully verify that the ISSN in your deposit is correct. If it is not, correct and resubmit your deposit.
If the ISSN matches the ISSN you believe is assigned to your title, check your ISSN against the ISSN assigned by the ISSN Register (or your ISSN registrar). Transcription errors may occur when the ISSN is assigned. If you are not able to verify your ISSN, contact support@crossref.org and we will look it up for you.

Updating or correcting title information, Best practices for journal titles

ISSNs_Books

Mon, 01 Jan 0001 00:00:00 +0000

Considerations for ISSNs and ISBNs in Books and Conference Proceedings deposits

With the release of schema version 4.3.0, changes have been made to the way Crossref handles ISSNs and ISBNs.

Previous schema versions allowed:

ISBN at the series level
ISSN at the volume level only
deposits without volume titles
book deposits without ISBNs

Changes as of version 4.3.0:

ISSN is bound to series title and must be present for all series deposits
Volume will be mandatory if series_metadata is present and volume level title is NOT present
The concept of a SET has been introduced (a finite series)

ISSN and ISBN verification:

A check digit validation has been implemented for all ISSNs and ISBNs
- invalid ISSNs and ISBNs will be rejected
Titles and ISSNs/ISBNs in deposits must match titles associated with ISSNs/ISBNs in the system. If a title, ISSN, or ISBN needs to be changed, contact support@crossref.org.

ISBN requirements for books:

ISBNs are strongly recommended but not required. A <noisbn> has been introduced with schema v. 4.3.0 to accommodate books published prior to ISBN availability. Either an ISBN or the <noisbn> element must be included in all book deposits.

Book deposit samples are available here: http://www.crossref.org/help/samples/

Including JATS abstracts in deposits

Mon, 01 Jan 0001 00:00:00 +0000

Include NLM/JATS abstracts in deposits

Abstracts from JATS XML may be included in Crossref deposits. A namespace prefix (jats) must be used for the abstract and all child elements.

Schema declaration:

<doi_batch version="4.3.6" xmlns="http://www.crossref.org/schema/4.3.6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.crossref.org/schema/4.3.6 http://www.crossref.org/schemas/crossref4.3.6.xsd" xmlns:jats="http://www.ncbi.nlm.nih.gov/JATS1">

Deposit example: {.p1}

. . . </person_name> </contributors> <jats:abstract><jats:p>We describe a method for cloning nucleic acid molecules onto the surfaces of 5-μm microbeads rather than in biological hosts. A unique tag sequence is attached to each molecule, and the tagged library is amplified. Unique tagging of the molecules is achieved by sampling a small fraction (1%) of a very large repertoire of tag sequences. The resulting library is hybridized to microbeads that each carry ≈10<jats:sup>6<jats:/sup> strands complementary to one of the tags. About 10<jats:sup>5<jats:/sup> copies of each molecule are collected on each microbead. Because such clones are segregated on microbeads, they can be operated on simultaneously and then assayed separately. To demonstrate the utility of this approach, we show how to label and extract microbeads bearing clones differentially expressed between two libraries by using a fluorescence-activated cell sorter (FACS). Because no prior information about the cloned molecules is required, this process is obviously useful where sequence databases are incomplete or nonexistent. More importantly, the process also permits the isolation of clones that are expressed only in given tissues or that are differentially expressed between normal and diseased states. Such clones then may be spotted on much more cost-effective, tissue- or disease-directed, low-density planar microarrays.</jats:p></jats:abstract> <publication_date media_type="print"> <year>2000</year>
</publication_date> . . .

Including non-Crossref DOIs in deposits

Mon, 01 Jan 0001 00:00:00 +0000

Including non-Crossref DOIs in deposits {.p1}

Publishers may now include non-Crossref DOIs in Crossref DOI deposits. These DOIs will be deposited as components. This feature allows publishers to deposit journal article or book DOIs and describe their association to content which has been assigned a DOI by another Registration Agency. Including a non-Crossref DOI in a deposit does not affect the registration of the DOI with Handle but the metadata for the DOI is added to the Crossref database.

For example: a journal article could define a relationship to a database which has been assigned a DOI via DataCite.

When depositing and registering a component DOI with Crossref, the DOI is enclosed within the <doi_data> element, which also encloses URL(s) within the <resource> and <collection> elements. Non-Crossref DOIs should be included within a <doi> tag, the <doi_data> element is not allowed:

<component_list> <component parent_relation="isReferencedBy"> <description>Dataset for parent article</description> <doi>10.5061/xxxxx</doi> </component> </component_list>

Components are currently how Crossref supports the identification of supplemental material. This feature will be enhanced to reflect terminology and organization defined by the NISO/NFAIS Supplemental Journal Article Materials Project.

Interpreting submission logs

Mon, 01 Jan 0001 00:00:00 +0000

Interpreting submission logs

Submission logs contain valuable information about items submitted to the Crossref system. After a file has been processed, a report is emailed to the address specified in the submission.

Successful submission + show/hide example

<?xml version=“1.0” encoding=“UTF-8”?>
<doi_batch_diagnostic>
<submission_id>9349810</submission_id> what is this?

<submission_id> identifies the job that processed this deposit. In the event of problem please include this ID in any messages you send to Crossref support.

<batch_id>FINAL_001</batch_id>
<record_diagnostic status=“Success”>
<doi>10.5555/second_conflict_003</doi> what is this?

<doi>is a DOI name submitted for deposit with submission ID 9349810

<msg>Successfully added</msg>
</record_diagnostic>
<batch_data>
<record_count>1</record_count> what is this?

<record_count> is the total number of items submitted

<success_count>1</success_count> what is this?

<success_count> number of items submitted successfully deposited or updated

<warning_count>0</warning_count> what is this?

<warning_count> is the number of items added with a warning. Warning and failure counts must be examined either manually or automatically and corrective action must be taken.

<failure_count>0</failure_count> what is this?

<failure_count> is the number of items rejected by the system.

</batch_data>
</doi_batch_diagnostic>

In this example, the number of items submitted (<record_count>) equals the number of successful deposits (<success_count>).

Submission with problems + show/hide example

<?xml version=“1.0” encoding=“UTF-8”?>
<doi_batch_diagnostic status=“completed” sp=“cr5.crossref.org”>
     <submission_id>394260418</submission_id>
     <batch_id>314668373.xml</batch_id>
     <record_diagnostic status=“Failure”> what is this?

A “Failure” status indicates an item was rejected.

<doi>10.5555/11111</doi>
<msg>Record not processed because submitted version: 20070904093839 is less or equal to previously submitted version (DOI match)</msg> what is this?

The <msg> details reasons for failure. See Errors and warning messages.

     </record_diagnostic>
     <record_diagnostic status=“Failure”>
          <doi>10.5555/22222</doi>
          <msg>Out of date version: 20070904093839</msg>
      </record_diagnostic>
      <record_diagnostic status=“Failure” msg_id=“4”>
         <doi>10.5555/33333</doi>
         <msg>Record not processed because submitted version: 20070904093839 is less or equal to previously submitted version (DOI match)</msg>
     </record_diagnostic>
     <record_diagnostic status=“Failure” msg_id=“4”>
          <doi>10.5555/44444</doi>
         <msg>Record not processed because submitted version: 20070904093839 is less or equal to previously submitted version (DOI match)</msg>
     </record_diagnostic>
     <record_diagnostic status=“Success”>
         <doi>10.5555/55555</doi>
         <msg>Successfully added</msg>
     </record_diagnostic>
<batch_data>
<record_count>5</record_count>
<success_count>1</success_count>
<warning_count>0</warning_count>
<failure_count>4</failure_count>
</batch_data>
</doi_batch_diagnostic>

This example contains failures (<failure_count>4</failure_count> ). Records with a status of “Failure” indicate the DOI was not deposited. A status of “Warning” indicates that the DOI was deposited but may need further action.

Each error should be corrected and the deposit resubmitted. See Error and warning messages for details.

If you do not receive an email:

verify that the email address included in your submission is correct
use the Submission Administration interface to retrieve your report
if you are still not able to retrieve your report, contact support@crossref.org. Please specify the time and date of your deposit.
Deposits whose XML will not parse will be rejected in their entirety.
All DOIs in the file will not be processed if any XML errors are encountered whether the error is just a simple omission of data from one record or a major structural problem with the XML.

Journal title-level DOIs

Mon, 01 Jan 0001 00:00:00 +0000

Journal title-level DOIs

Crossref publishers are not required to create DOIs for journal titles but are strongly encouraged to do so. There are no deposit fees for title-level DOIs.

Title-level DOI Best practice are as follows:

A distinct DOI should be created for each version of a title deposited with Crossref. Any changes requiring a new ISSN should result in a new title-level DOI.
A title-level DOI should resolve to a response page that displays the same title and ISSN (when available) recorded in the Crossref database.
Once assigned, a title-level DOI should be maintained.
Responsibility for maintaining a title-level DOI transfers to the new owner when title ownership is transferred.
As with all DOIs registered via Crossref, the DOI being resolved should appear on the DOI response page.

Depositing title-level DOIs

Title, volume, and issue DOIs may be included with journal article deposits, or may be deposited separately. Once deposited, a journal, volume, or issue DOI does not need to be included in subsequent deposits but, as with all DOIs, the URL should be maintained. The web deposit form supports deposit of title-level DOIs. Sample title-only deposit files are available here: with ISSN | without ISSN

The ISSN standard, ISO 3297, recommends that a DOI suffix contain the ISSN (with hyphen), preceded by the lowercase letters “issn” and a period, for example: 10.5930/issn.1994-4683
Journal DOIs are required to comply with COUNTER release 4.

License information

Mon, 01 Jan 0001 00:00:00 +0000

Depositing license metadata (Access Indicators)

Members may include access indicators (most commonly text and data mining license information) in deposits. An additional element (<ai:program>) has been added beginning with schema version 4.3.2 to support the Access Indicators schema (AccessIndicators.xsd).

License information metadata collected includes:

license URL element (license_ref)
start_date attribute, optional, date formated YYYY-MM-DD
*applies_to *attribute, optional, allowed values are:
- vor (version of record)
- am (accepted manuscript)
- tdm (text mining)

Access Indicators may be included in a metadata deposit or submitted as a resource deposit, and may be included with Crossmark metadata where applicable. The ‘ai’ namespace must be included in the schema declaration, for example:

<doi_batch version=“4.3.6” xmlns=“http://www.crossref.org/schema/4.3.6" xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=“http://www.crossref.org/schema/4.3.6 http://www.crossref.org/schemas/crossref4.3.6.xsd" xmlns:ai=“http://www.crossref.org/AccessIndicators.xsd">

Sample metadata deposit:

<publication_date media_type="print"> <year>2013</year> </publication_date> <pages> <first_page>13</first_page> </pages> <ai:program name="AccessIndicators"> <ai:license_ref applies_to="vor" start_date="2011-02-11">http://www.crossref.org/license</ai:license_ref> </ai:program> <doi_data> <doi>10.5555/openAI_test2</doi> <resource>http://www.crossref.org/test</resource> </doi_data>

MIssed Conflict report

Mon, 01 Jan 0001 00:00:00 +0000

Missed conflict report

Conflicts occur when two (or more) DOIs share the same bibliographic metadata. Conflicts are usually flagged upon deposit. In some situations this doesn’t happen, creating a missed conflict.

Reasons a missed conflict may occur:

Two DOIs are deposited for the same item, but the metadata is slightly different (DOI A deposited with an online publication date of 2011, DOI B deposited with a print publication date of 1972)
DOIs were deposited with a unique item number (more info) Prior to 2008, DOIs containing unique item numbers (supplied in the *<publisher_item>* element) were not checked for conflicts. This feature was discontinued because of misuse.

The missed conflict report compares article titles across data for a specified journal or journals.

Accessing the missed conflict report

To retrieve a missed conflict report for a title:

Locate the title in the browsable title list by searching or browsing
Select the icon at the far right of the title + show/hide example
The missed conflict interface will pop up in a second window. Enter your email address in the appropriate field. Multiple title IDs can be included in a single request if needed. + show/hide example

A report will be emailed to the address provided in step 3. This report lists all DOIs with identical article titles that have not been flagged as conflicts. + show/hide example

Machine interfaces and APIs

Mon, 01 Jan 0001 00:00:00 +0000

Crossref Machine interfaces and APIs

File submissions

HTTPS POST batch deposit or query files

Query APIs

Crossref Labs APIs

REST API at http://api.crossref.org/
Crossref Metadata Search

* these APIs are available for use but under development, performance and availability is not guaranteed. Additional tools and APIs are available at labs.crossref.org.

Submission Tracking

MathML

Mon, 01 Jan 0001 00:00:00 +0000

Including MathML in deposits

Beginning with schema version 4.3.2, MathML may be included in the title, subtitle, and original_language_title elements. The MathML namespace (mml) must be defined in the schema declaration, for example:

<doi_batch version="4.3.2" xmlns="http://www.crossref.org/schema/4.3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/schema/4.3.2 http://www.crossref.org/schemas/crossref4.3.2.xsd" xmlns:jats="http://www.ncbi.nlm.nih.gov/JATS1" xmlns:mml="http://www.w3.org/1998/Math/MathML">

and all MathML markup must include a* mml* namespace prefix:

<journal_article publication_type="full_text"> <titles> <title>Selectron production at an <mml:math><mml:msup><mml:mi>e</mml:mi><mml:mo>−</mml:mo></mml:msup><mml:msup><mml:mi>e</mml:mi><mml:mo>−</mml:mo></mml:msup></mml:math> linear collider with transversely polarized beams</title> </titles>

Member_info

Mon, 01 Jan 0001 00:00:00 +0000

Members must log in to access select reports linked from the Members area of the Crossref website. The username and password are different than the member-specific login used to access the Crossref system. Contact support@crossref.org for the username and password.

Missing Metadata / Field Report

Mon, 01 Jan 0001 00:00:00 +0000

Missing Metadata / Field Report

The Field (or Missing Metadata) report gives details on metadata completion and can be accessed by selecting the listed next to each publisher name in the Depositor Report. Fields checked are volume, issue, page, author, and article title. + show/hide sample field report

Selecting a title will retrieve a list of DOIs for the title and flagged fields for each DOI. For example, the DOIs in this report lack page and author information: + show/hide field report details

Although the Crossref deposit schema specifies that some bibliographic metadata is optional for DOI registration purposes, we strongly encourage members to register comprehensive metadata for each DOI deposited. Review Best practice for depositing for more information.

NLM/JATS to Crossref conversion

Mon, 01 Jan 0001 00:00:00 +0000

NISO JATS to Crossref conversion (beta)

We are potentially going to allow members to send NLM / JATS metadata directly to Crossref. We’ve prepared a preliminary XSLT conversion:

NLM.JATS2Crossref.v3.0.xsl

Please note:

The journal title used for Crossref deposits be included in the <journal-title element>.
The DOI should be included in <article-id> with attribute pub-id-type=‘doi’
The DOI URL should be included in <self-uri>
The JATS DTD does not have an appropriate place to include the email element used in Crossref deposits, this currently needs to be added manually. When we create the conversion we’ll probably allow this to be included as an upload parameter.

Comments are welcome, please email support@crossref.org.

New Page

Mon, 01 Jan 0001 00:00:00 +0000

DOIs and DSpace repositories

*THE-DOI* = DOI-prefix / DSpace-prefix / Dspace-suffix *Example:* 10.1575/1912/1099

The URL assigned to the DOI should use the form http://hdl.handle.net/DSpace-prefix/DSpace-suffix

*Example:* http://hdl.handle.net/1912/1099 DOI link: http://dx.doi.org/THE-DOI

New Page

Mon, 01 Jan 0001 00:00:00 +0000

Sample DOI suffix patterns

Crossref members have established a variety of schemes for creating their DOI suffixes. One or more of these patterns may be appropriate for your situation.

Crossref Member Sample DOI Notes

American Institute of Physics 10.1063/1.125173 Sequential numbers in which the first node designates the production center that assigned the DOI suffix American Chemical Society 10.1021/cm960127g American Mathematical Society 10.1090/S0002-9939-00-05422-8 Uses existing identifier PII American Physical Society 10.1103/PhysRevLett.88.088302 The APS has replaced page numbers with an article code that can be assigned on acceptance of an article; the DOI uses a journal abbreviation, volume number, and the article code CSHL Press 10.1101/gr.10.12.1841 Geological Society of America 10.1130/0091-7613(2001) IEEE 10.1109/16.8842 MIT Press 10.1162/003355300554872 Oxford University Press 10.1093/ageing/29.1.57 The Royal Society 10.1098/rspa.2001.0787 UChicago Press 10.1086/301055 Sequential numbers

New Page

Mon, 01 Jan 0001 00:00:00 +0000

Standards

Standard is the top-level element for deposit of metadata about standards developed by Standards Development Organizations (SDOs) or Consortia. The metadata for standards differ from other content types primarily in the inclusion of additional designators along with the title which are commonly used when referring to a standard.

Standards are assigned a DOI at the title level and may also have DOIs assigned to lower level “content-items”. Standards deposits contain several pieces of standard-specific metadata, including standard designators and standards body information (sample deposit).

Designator types

All standards have a designator that is used as a primary identifier. crossref4.3.6.xsd allows for a number of designator types to be applied to a DOI. A primary designator must be included in each DOI deposit. One of the following designator types must be supplied:

As-published: recorded in <std_designator> (child of <std_as_published>), designator for the standard being deposited. This is an item-level designator. Typically includes the year of initial publication plus additional information such as amendment number and/or revision/reaffirmation year, for example: ASTM D6/D6M-95(2011)e1 is a designator for an ASTM standard. Any undated, family, and set designators related to the designator supplied in <std_designator> may be recorded in the corresponding attributes (example:<std_designator undated=”ASTM D6/D6M-95”> ASTM D6/D6M-95(2011)</std_designator>).

Optional: an alternate as-published designator may be recorded in <std_alt_as_published>.This is intended to accommodate minor changes to a standard that do not merit assigning a new DOI. A variant form designator may also be supplied to accommodate differing forms of a designator.
Undated: to be recorded in <std_undated_designator>. An undated designator removes the year component that specifies a particular revision. Undated designators refer to a single document series. For example: ASTM C90, IEC 60601-2-11, ISO/IEC 19757-2
Family:recorded in <std_family_designator>, a collection of standards which are conceptually grouped together where that grouping is not necessarily reflected in the designator in an obvious way.For example, the ISO 9000 family includes ISO 9001, ISO 9004, ISO 19011.
Set:recorded in <std_set_designator>. A set, also referred to as truncated form, is composed of several parts (standards that are divided into separate documents). For example, ISO 19757 is a standard in 11 parts, with the individual documents known as ISO 19757-2 where the “-” denotes a part.

Optional designators:

Some optional designators may be supplied in deposits in addition to a required dated, undated, family, or set designator. They are supplied to accommodate query matching but are not considered title-level designators. These are:

Variant form:Alternate versions of a designator may be supplied in <std_variant_form>. Variant form captures stylized forms that don’t accurately reflect the true standard designator but are needed due to business practices (e.g. IEEE formal designators have “std” while the display of them does not). Variant forms may be applied to <std_alt_as_published>, <std_as_published>, <std_set_designator> and <std_undated_designator>
Alternate script: recorded in <std_alt_script>, accommodates designators that are published using multiple character sets
Supersedes:to be recorded in <std_supersedes>. Designator for standard being replaced by the standard being deposited.
Adopted from: to be recorded in <std_adopted_from>. Designator for standard from which the current deposit is adopted.
Revision of:to be recorded in <std_revision_of>. Designator for the previous revision of the standard being deposited.

Standards body information

The <standards_body> wrapper element has two children:

standards_body_name:the full name of the standards body
standards_body_acronym:acronym of the standards body

Both child elements are required and should reflect the standards body name and acronym used when the standard was published. Changes in standards body names and acronyms over time will be accounted for within Crossref’s query mechanism.

History

Crossref began accepting DOI deposits for standards in 2005. The schema was modified significantly for standards with the inception of the Standards Technical Working Group. Significant changes to the deposit and indexing of designators were made with schema version 4.3.6, as a result standards may only be deposited with crossref4.3.6.xsd.

The Standards Technical Working Group is currently active, contact pfeeney@crossref.org if you are interested in participating.

New Page

Mon, 01 Jan 0001 00:00:00 +0000

Select a registrant prefix if you need to limit your results by prefix and are confident that your XML is valid. Only parsable submissions can be connected with a registrant prefix.

Notification Callback Service

Mon, 01 Jan 0001 00:00:00 +0000

Notification Callback Service

The notification callback service (NC) notifies members that a submission log is available for a submission (metadata deposit, batch query, or cited-by q uerying). This service provides a HTTP(S) URL from which the result can be retrieved.

This is a new service and is subject to change. Please contact support@crossref.org if you are interested in implementing this service.

How it works

The callback will be an HTTP(S) request to a URL provided by the member (notify-url) with all data relayed via HTTP headers. The notification specifies the availability of the result, some context of the request, and an HTTP(S) url from which to get the result. The submission log may then be retrieved using the HTTP(S) URL.

The headers use the simple name and value structure; that is, the value has no additional structure that divides it into parts. To ensure that all Unicode values can be accommodated all header values will be UTF-8 encoded.

When the notify-url is used the following HTTP headers are provided:

CROSSREF-NOTIFY-ENDPOINT: the notify-endpoint. Required header.

CROSSREF-EXTERNAL-ID: the id given by the member with regards to the request. For metadata deposits, for example, it is the value of the doi_batch_id element. Optional header.

CROSSREF-INTERNAL-ID: the id given by Crossref with regards to the request. Optional header.

CROSSREF-RETRIEVE-URL: the URL for the member to use to retrieve the request’s result. Since the HTTP header value is UTF-8 encoded, the URL will contain no URI encodings. For example, an “Á” will not be encoded as “%C3%81”.

Other headers might include:

CROSSREF-SERVICE-DATE: the date and time stamp of the service request. See format specification in RFC 2616.

CROSSREF-RETRIEVE-URL-EXPIRATION-DATE: the timestamp after which service result is no longer available at the given retrieve-url.

For example: + show / hide example

for the submission 1368966558 the notification would be as follows (new lines have been added between header name and header value to improve readability):

...

CROSSREF-NOTIFY-ENDPOINT:

F8DD070C-89A9-4B82-B77E-1CADCD989DAE

CROSSREF-EXTERNAL-ID:

apsxref:7ca42f54-093f-11e4-b65b-005056b31eb6

CROSSREF-INTERNAL-ID:

1368966558

CROSSREF-SERVICE-DATE:

Fri, 11 Jul 2014 21:08:24 GMT

CROSSREF-RETRIEVE-URL-EXPIRATION-DATE:

Fri, 18 Jul 2014 21:08:24 GMT

CROSSREF-RETRIEVE-URL:

http://doi.crossref.org/notification/retrieve/67BCBED2-7AE2-4FD7-B90E-514E19B1DE49

...

Querying for past callbacks

The notification callback service can be queried for past callbacks. The query is is implemented as an HTTP service.(Access control and limits to end-points and time frames TBD).

The query takes 3 criteria, the notify-endpoints, an inclusive from timestamp, and an exclusive until timestamp. All timestamp use the ISO 8061 format YYYY-MM-DD’T’hh:mm:ss’Z’, eg “2014-07-23T14:43:01Z”.

The query results in a JSON array of callbacks. For example, querying for the single endpoint “1CFA094C-4876-497E-976B-6A6404652FC2” returns:

[

{

"notify-endpoint": "1CFA094C-4876-497E-976B-6A6404652FC2",

"external-id": "apsxref:7ca42f54-093f-11e4-b65b-005056b31eb6",

"service-date": "2014-07-14T21:08:24Z",

"retrieve-url": "http://doi.crossref.org/.../67...49",

"retrieve-url-expiration-date": "2014-07-11T21:08:24Z",

"audit": [

{

"notify-url" : "http://abc.org/crossref/callbacks",

"date" : "2014-07-14T21:09:00Z",

"explanation": "http status 200"

}

]

},

{

"notify-endpoint": "1CFA094C-4876-497E-976B-6A6404652FC2",

"external-id": ...

},

...

]

A flat structure is used to aid processing the result as a stream. There is no order defined.

The *audit*item is a record of attempted callbacks. It details the notify-endpoint’s notify-url used at the time of the callback, the timestamp of the callback, and the HTTP status of the callback. If more than one attempt has been tried then the audit array will contain multiple elements; there is no order defined.

The query service is currently available at:

http://doi.crossref.org/notification-callback/exec/findNotificationCallbackAttempts?usr=USER&pwd=PASSWORD&notifyEndpoints=ENDPOINT&from=2014-01-01&until=2014-12-31

The *usr* and pwd are the member’s deposit credentials. The ENDPOINT value is a notify-endpoint or a space separated set of notify-endpoints.

Terms

notify-endpoint:an opaque token used to select a notify-url. The token will be anonymous and difficult to guess. The notify-endpoint is provided by the member. The notify-endpoint is associated with one notify-url(many notify-endpoints can be associated with the same notify-url).

notify-url: the URL that the member provides that is used to notify them of the availability of a service request’s result. How the URL is provided to Crossref will depend on the service.

notify-payload: the data that specifies what service request this notification is for. This payload will use HTTP headers so as to be HTTP method (POST, PUT, etc) neutral.

retrieve-url: the URL that Crossref provides that is used by the member to get the service request result.

retrieve-payload: the service result. Each service will define its own result content-type (that is very much like what would be sent in email today).

notification-authentication: This is the method of authentication Crossref will use with the notify-url. Credentials are provided by the member.

retrieval-authentication:This is the method of authentication the member will use with the retrieve-url. The credentials are provided by Crossref.

OAI-PMH query interface

Mon, 01 Jan 0001 00:00:00 +0000

Using OAI-PMH

Crossref operates an OAI-PMH service for the distribution of metadata to subscribers. This system is based on the OCLC version 2 repository framework and implements the interface as documented at http://www.openarchives.org/OAI/openarchivesprotocol.html.

Access to Crossref’s service for retrieving DOI metadata is regulated by the IP address of a server which will be performing a harvest. Our repository supports selective harvesting according to sets defined by the hierarchy of publisher and journal title.

Our service allows public access to two OAI verbs which allow for discovery of coverage information

Setspecs are formatted as follows:

content type:prefix:pubID (ex: J:10.1002:4, the publisher Wiley, journal Applied Organometallic Chemistry)
content type:prefix (ex: J:10.1002, journals owned by publisher Wiley)
The *from* and *until* dates are when the DOI record was deposited with Crossref, not the published date of the item. Thus a request for records from yesterday (until now) will return all records added or changed between then and now irrespecive of the record’s publication date.
Content type are: J for journals, B for book or conference proceeding titles, and S for series.
Due to the size of the repository it is highly discouraged to perform a ListRecords action for the entire collection. Use of the ListRecords verb must include a SET specification.

With the ListSets request the set parameter is optional. Leaving off the set parameter will return a listing of all publishers, all their journal titles and each year of publication for which we have DOIs.

With the ListIdentifers request the set, from, and until parameters are optional. The from and until parameters are used to specify dates when the DOIs were registered with Crossref and not the publication date.

http://oai.crossref.org/OAIHandler?verb=ListIdentifiers&metadataPrefix=cr_unixml&from=2010-08-11

The default set for both ListIdentifiers and ListRecords is J (journals). A set (B for books or conference proceedings, S for series) must be specified to retrieve non-journal data.

Resumption Tokens

Many OAI requests are too big to be retrieved in a single transaction. If a given response contains a resumption token, the user must make an additional request to retrieve the rest of the data. Resumption tokens remain viable for 24 hours.

The resumption token includes an expiration date of 24 hours:

<resumptionToken expirationDate="2015-10-28T00:00:00">c6cafedc-ef48-42a3-847c-b682dc58b617</resumptionToken>

The token should be appended to the end of the next request:

http://oai.crossref.org/OAIHandler?verb=ListSets&set=J:10.1007&resumptionToken=c6cafedc-ef48-42a3-847c-b682dc58b617

Metadata Services - What data is available

Crossref’s Metadata Service is available based on subscription. After an organization applies for subscription members of Crossref may decide if they wish for their metadata to be included in distributions to the subscribing organization (knows as an opportunity to ‘opt-out’). This may result in the subscribing organization being able to retrieve less than the full set of metadata available at Crossref. Upon acceptance of an application the subscriber will supply Crossref with two IP addresses from which they will be allowed to retrieve metadata. Any request received from these IP addresses will be filtered so as to exclude non-participating Crossref member metadata. The two publicly available requests mentioned above are not subject to this limitation when the requests come from an IP address not assigned to a known subscriber. These two requests when received from a subscriber’s registered IP addresses will only return data pertinent to that subscriber (e.g. a ListSets request will omit any publisher who has chosen not to distribute to that subscriber).

Crossref may also establish a subscriber using an ‘opt-in’ model where each publisher must specifically request that their data be enabled for transmission to such a recipient.

Opt-out and opt-in is established at the title level. Titles may have more than one depositor, but OAI delivery is determined by the prefix identified as the owner in the Crossref system.

Initial data loads

As mentioned above, the size of the Crossref repository precludes using one OAI request to retrieve all the available data. Often a subscriber first obtains a list of the available sets using the ListSets request and then repeatedly submit ListRecords requests for each publisher. This approach can require a substantial amount of time. Upon request Crossref staff can produce an archive of all the data available to a given subscriber which can then be downloaded via FTP. Please submit requests to support@crossref.org.

A sample application for harvesting Crossref OAI data is available at http://www.crossref.org/08downloads/oaipmhRequest.zip

Obtaining a DOI prefix

Mon, 01 Jan 0001 00:00:00 +0000

Obtaining a DOI prefix

Once your organization joins Crossref, Crossref assigns it a unique DOI prefix beginning with “10.”. You do not need to get a DOI prefix prior to joining Crossref nor pay a separate fee to the International DOI Foundation (IDF). Member organizations may also obtain multiple DOI prefixes upon request.

Note that the prefix of a DOI does not reliably identify the current publisher of the item. Once you associate an individual DOI with a particular content item, the DOI is permanently assigned to that content regardless of the owner. While specific publishers must assign DOIs using their unique prefix, ownership and control of individual DOIs can (and should) be transferred when a title changes hands.

OpenURL query interface

Mon, 01 Jan 0001 00:00:00 +0000

Using the Open URL Query Interface

For basic information on OpenURL, see DOIs, OpenURL, and link resolvers.

OpenURL Accounts

Using a login to access Crossref’s OpenURL Query Interface is required. We request that users obtain and use a login to help monitor usage and deal with problems should they arise. OpenURL users who are already Crossref members may use their Crossref system account. Non members may obtain a free query services account.

For Crossref members using username/password:

https://doi.crossref.org/openurl?pid=**username:password**&aulast=Maas%20LRM&title= JOURNAL%20OF%20PHYSICAL%20OCEANOGRAPHY&volume=32&issue=3&spage=870&date=2002

For Crossref Query Services accounts:

https://doi.crossref.org/openurl?pid=**name@someplace.com**&aulast=Maas%20LRM&title= JOURNAL%20OF%20PHYSICAL%20OCEANOGRAPHY&volume=32&issue=3&spage=870&date=2002

Metadata queries

Crossref maintains an OpenURLQuery Interface that accepts metadata, searches to find a matching DOI, and redirects the user to the target of the DOI.

For example, a user might submit the following query:

https://doi.crossref.org/openurl?pid=username:password&aulast=Maas%20LRM&title= JOURNAL%20OF%20PHYSICAL%20OCEANOGRAPHY&volume=32&issue=3&spage=870&date=2002

The OpenURL Query Interface would find the appropriate DOI—in this case, 10.1175/1520-0485(2002)032<0870:CT>2.0.CO;2—and redirect the user to the DOI response page at http://dx.doi.org/10.1175/1520-0485(2002)032<0870:CT>2.0.CO;2.

In most instances, only a single DOI will be returned. If more than one DOI is returned, the user will be directed to a list of all available DOIs. For example, the query: http://www.crossref.org/openurl?pid=username:password&title=Science&aulast=Fernández&date=2009 will return multiple results. + show/hide example

OpenURL query parameters

The OpenURL Query Interface can accept these parameters:

Citation metadata parameters:

issn – ISSN
title - journal title
aulast - last name (preferably of first author)
volume
issue
spage - first page
date - publication year (YYYY)
*stitle*– Short title, which may be supplied as an alternative to title

Other parameters:

*pid*or sid – Your Crossref-supplied login name and password; in older forms, sid was used instead of pid (which is preferred)
redirect – Set to false to return the DOI in XML format instead of redirecting to the target URL (the default is true)
multihit – Set to true to return DOIs for more than one content item if the Crossref system does not find an exact match (the default is false)
*format - *set to unixref to return metadata in UNIXREF format (a more complete set of metadata)

Results are returned in XML format.

Sample results:

Single match found: + show/hide example

<?xml version="1.0" encoding="UTF-8" ?> <doi_batch version="0.3"> <head> <doi_batch_id>Crossref::Resolver_26-Feb-2004@09:25:12</doi_batch_id> <timestamp>26-Feb-2004@09:25:12</timestamp> <depositor> <name /> <email_address /> </depositor> <registrant /> </head> <body> <doi_record type="full_text" key=""> <doi_data> <doi>10.1006/jmbi.2000.4282</doi> <url /> </doi_data> <journal_article_metadata> <article> <author sequence="first"> <given_name /> <surname>Jiang</surname> </author> <date type="print"> <year>2001</year> </date> <enumeration> <volume>305</volume> <issue>3</issue> <first_page>377</first_page> </enumeration> </article> <journal> <full_title>Journal of Molecular Biology</full_title> <issn type="print">00222836</issn> <issn type="electronic">10898638</issn> </journal> </journal_article_metadata> </doi_record> </body> </doi_batch>

Multiple matches found: + show/hide example

<?xml version="1.0" encoding="UTF-8" ?> <crossref_result version="2.0" xmlns="http://www.crossref.org/qrschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 http://www.crossref.org/qrschema/crossref_query_output2.0.xsd"> <query_result> <head> <email_address>your@email.com</email_address> <doi_batch_id>w001</doi_batch_id> </head> <body> <query key="555-555" status="multiresolved"> <doi>10.1016/S0360-3016(02)03429-6</doi> <issn type="print">03603016</issn> <journal_title>International Journal of Radiation Oncology*Biology*Physics</journal_title> <author>KIM</author> <volume>54</volume> <issue>2</issue> <first_page>215</first_page> <year>2002</year> <publication_type>full_text</publication_type> <article_title>Potential radiation sensitizing effect of SU5416 by down-regulating the COX-2 expression in human lung cancer cells</article_title> </query> - <query key="555-555" status="multiresolved"> <doi>10.1016/S0360-3016(02)03428-4</doi> <issn type="print">03603016</issn> <journal_title>International Journal of Radiation Oncology*Biology*Physics</journal_title> <author>WILLIAMS</author> <volume>54</volume> <issue>2</issue> <first_page>215</first_page> <year>2002</year> <publication_type>full_text</publication_type> <article_title>Effect of the administration of lovastatin on the development of pulmonary fibrosis following whole lung irradiation in a mouse model</article_title> </query> </body> </query_result> </crossref_result>

Sample queries:

redirect=“false”:

https://doi.crossref.org/openurl?issn=03770273&aulast=Walker&volume=54&spage=117&date=1983&redirect=false&pid=username:password

multihit=“true/false/exact”:

https://doi.crossref.org/openurl?issn=03603016&volume=54&issue=2&spage=215&date=2002&multihit=true&pid=username:password

DOI queries

Crossref supports DOI queries formatted as OpenURL version 0.1 requests. This metadata includes identifiers (title and/or ISSN), first author, enumeration (volume issue page), and year, as shown here:

Open URL query: {style=“font-weight: bold; “}

https://doi.crossref.org/openurl/?pid=username:password&id=doi:10.1103/PhysRev.47.777&noredirect=true

Crossref query: {style=“font-weight: bold; “}

https://doi.crossref.org/servlet/query?pid=username:password&id=10.1006/jmbi.2000.4282

Like metadata queries, DOI query results are returned in XML format.

The default result format for OpenURL is xsd_xml. For more robust metadata, use the *format* parameter and specify unixref:

https://doi.crossref.org/openurl/?pid=username:password**&format=unixref**&id=doi:10.1103/PhysRev.47.777&noredirect=true

NISO 0.1 or 1.0 URLs:

Crossref also supports NISO 0.1 and 1.0 URLs as well as some common deviations. In general it supports the San Antonio Profile #1, including in-line, by-value, and by-reference. In the presence of a “url_ver= Z39.88-2004” parameter this service will operate on a “info:ofi/fmt:kev:mtx:ctx” context format with referent formats “info:ofi/fmt:kev:mtx:journal” or “info:ofi/fmt:kev:mtx:book”.

Simple reverse lookup:

https://doi.crossref.org/openurl?pid=username:password&url_ver=Z39.88-2004&rft_id=info:doi/10.1103/PhysRev.47.777

Retrieve a DOI’s metadata:

https://doi.crossref.org/openurl?pid=username:password&url_ver=Z39.88-2004&rft_id=info:doi/10.1361/15477020418786&noredirect=true

A journal article lookup:

https://doi.crossref.org/openurl?pid=username:password&url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.atitle=Isolation of a common receptor for coxsackie B&rft.jtitle=Science&rft.aulast=Bergelson&rft.auinit=J&rft.date=1997&rft.volume=275&rft.spage=1320&rft.epage=1323

Opening a library account

Mon, 01 Jan 0001 00:00:00 +0000

Crossref for libraries

Through Crossref, libraries can create links to Crossref member publishers without signing bilateral linking agreements with each publisher, and without having to track publishers’ individual linking schemes. The Crossref system also serves as a source of metadata to enhance OpenURL-based local link resolvers and supports DOI re-direction for the purposes of localized linking within library holdings. Some libraries have created their own link resolvers, and many libraries purchase the services of one of a number of vendors who now provide link resolution software.

In most cases, information providers (publisher, database producers, and so on) use Crossref to add DOIs to their content and databases, so libraries do not need to use Crossref for DOI retrieval alone. If libraries host local content, the content providers should add DOIs before delivering the content. Users browsing online content will see DOI links and click them; there is no charge for clicking and following DOIs links.

There is no charge for libraries to get a Crossref account to retrieve DOIs or metadata. More information is available on the Crossref website.

To view a list of libraries with Crossref accounts, see Libraries on the Crossref web site.
For information about how the DOI integrates with local link servers, see DOIs, OpenURL, and link resolvers.

Outbound linking

Mon, 01 Jan 0001 00:00:00 +0000

Outbound linking

Crossref Members are required to create outbound DOI links within their references, meaning members must add DOI links (when available) to the reference list for journal articles deposited with Crossref. Outbound linking for other content types is encouraged but not required.

Creating outbound links

1. Query for DOIs: The first step is to retrieve DOIs for all available references. Several different query interfaces are available:

Simple Text Query form: cut-and-paste reference lists into a web form. This is a manual interface suitable for low volume querying.
Simple Text Query upload:upload reference lists as .txt files and receive query results via email. This is a manual interface suitable for low volume querying.
XML Queries: XML formatted using the Crossref query schema may be submitted to our system as individual requests or as a batch upload. XML querying allows for significant control over query execution and results, and is the preferred method of querying for most members (details).

2. Link to DOIs in your references: After DOIs have been retrieved via querying, members must display and link DOIs in their references. Links to Crossref DOIs should comply with our DOI Display Guidelines.

Sample outbound linking);)

Queries & retrieving metadata, Querying with XML, crossref_query_input2.0.xsd schema documentation, Crossref DOI Display Guidelines, Building URLs for DOIs containing special characters

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Queries & retrieving metadata

Unlike general purpose search engines, the Crossref system is designed to (typically) return only one DOI, the one that best fits the metadata supplied in the query. This behavior is essential since the majority of queries sent to Crossref come from publisher and library automated systems which are not equipped to deal with a multiple choice result. Options for retrieving multiple results are available.

The Crossref system primarily operates on XML data. All metadata deposits are done using XML which complies with Crossref deposit schema. Some interfaces are available for individual use. XML is the recommended method for machine-based querying as it allows for a significant amount of control over query execution. Query results are returned as XML as well.

In addition to query transactions Crossref also makes metadata available in bulk transactions through Crossref Metadata Services.

DOIs and metadata may also be retrieved using Crossref Metadata Search (user interface) or the Crossref REST API. This interface is not currently suitable for automated matching of citations to DOIs as results can sometimes be approximate - all results containing search terms are returned, the first result may not be the most appropriate match.

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Crossref Services

Crossref supports a number of services and initiatives that complement DOI registration and linking:

CrossCheck
Crossmark: general or technical information
Crossref Metadata Services (CMS)
Cited-by linking
funding
Crossref Text and Data Mining:general or technical information

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Funding Data (previously known as FundRef)

The funding data service collects funding source information for publications deposited with Crossref. An overview is available on the Crossref website. Implementation instructions are detailed below and include:

Crossref schema changes
Funder and award number hierarchy
Instructions for deleting or updating funding metadata
Examples

BEFORE YOU DEPOSIT:

Funder_name AND funder_identifier must both be included when the funding organization exists in the Funder Registry. Award numbers must be included when available.
Correct nesting of funder names and identifiers is essentialas it significantly impacts how funders, funder identifiers, and award numbers are related to each other.

Correct: In this example, funder “National Science Foundation” is associated with the funder identifier “http://dx.doi.org/10.13039.10000001"

<fr:assertion name="funder_name">National Science Foundation <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039.10000001</fr:assertion>
</fr:assertion>

Incorrect: Here, the funder name and funder identifier are not nested - these assertions will be indexed as separate funders.

<fr:assertion name="funder_name">National Science Foundation</assertion> <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039.10000001</fr:assertion>

The purpose of funder groups is to establish relationships between funders and award numbers. A funder group assertion should only be used to associate funder names and identifiers with award numbers when multiple funders are present.

Funding data deposit with one group of funders (no “fundgroup” needed):

Funding data deposit with two fundgroups:

Incorrect: Groups used to associate funder names with funder identifiers, these need to be nested as described above.
Deposits using a funder_identifier that is not taken from the Open Funder Registry will be rejected.
Deposits with only funder_name (no funder_identifier) are not considered valid funding data deposits and will not appear in funding Search or the search API.
If you have previously deposited funder names without funder IDs you should use the “get funders” API to see if the funder names have since been added to the Registry. You should then re-deposit your funding data with the funder IDs.

Depositing funding metadata

Funding metadata must include the name of the funding organization AND the funder identifier, where the funding organization is listed in the Registry, and should include an award/grant number. Funder names should only be deposited without the accompanying ID when the funder is not found in the Registry. These deposits will not be considered valid records until such a time as the funder is added to the database and they are re-deposited with an ID. To this end it is critical that publishers do their utmost to match submitted or extracted funding data to the Registry, which covers all major international funders and a growing number of lesser-known organisations.

Crossmark participantsshould nest funding data within the <crossmark> element, for example:

<crossmark> <crossmark_version>1</crossmark_version> <crossmark_policy>10.5555/cm_1</crossmark_policy> <crossmark_domains> <crossmark_domain><domain>www.crossref.org</domain></crossmark_domain> </crossmark_domains> <crossmark_domain_exclusive>true</crossmark_domain_exclusive> <updates> <update type="correction" label="Correction" date="2011-04-10">10.5555/cm_test2.1</update> </updates> <custom_metadata> <assertion name="received" label="Received" group_name="publication_history" group_label="Publication History">2011-04-12</assertion> <fr:program name="fundref"> <fr:assertion name=“funder_name”>IMA Funder
<fr:assertion name=“funder_identifier”>http://dx.doi.org/10.13039/xxxxxxxxxx \ \
<fr:assertion name=“award_number”>HPC-227</fr:assertion

</fr:program>

</custom_metadata> </crossmark>

Members not participating in Crossmark may deposit funding metadata along with article metadata, for example:``

   ... <publication_date media_type="print">   <year>2011</year> </publication_date> <pages>      <first_page>15</first_page> </pages>    <fr:program name="fundref"> <fr:assertion name="funder_name">ABC Inc.
<fr:assertion name=“funder_identifier”>http://dx.doi.org/10.13039/xxxxxxxxxx\    \
   <fr:assertion name="award_number">BXDFSDS</fr:assertion> </fr:program> <doi_data> <doi>10.5555/cm_test_1.1</doi> <resource>https://www.crossref.org/crossmark/index.html</resource>     </doi_data> </journal_article>

Funding data schema

The <fr:program> element has been added to the deposit schema (crossref4.3.6.xsd | documentation) to support the import of the fundref.xsd schema (documentation). The fundref namespace (xmlns:fr=https://www.crossref.org/fundref.xsd) must be included in the schema declaration, for example:

<doi_batch xmlns="http://www.crossref.org/schema/4.3.6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fr="https://www.crossref.org/fundref.xsd" xsi:schemaLocation="http://www.crossref.org/schema/4.3.6 http://www.crossref.org/schemas/crossref4.3.6.xsd" version="4.3.1">

To accommodate integration with Crossmark, the fundref.xsd consists of a series of nested <fr:assertion> tags with enumerated name attributes. The name attributes are:

fundgroup: used to group a funder and its associated award number(s) for items with multiple funders.
funder_name: name of the funding agency as it appears in the funding Registry. Funder names that do not match those in the registry will be accepted to cover instances where the funding organization is not listed.
funder_identifier: funding agency identifier in the form of a DOI, must be nested within the “funder_name” assertion. The funder_identifier must be taken from the funding Registry and cannot be created by the publisher. Deposits with no funder_identifier do not qualify as funding records.
award_number: grant number or other fund identifier

“funder_name” AND “funder_identifier” must be present in a deposit where the funding body is listed in the Funder Registry. Multiple ”funder_name”, “funder_identifier”, and “award_number” assertions may be included.

Funder and award number hierarchy

A relationship between “funder_identifier” and “funder_name” is established by nesting “funder_identifier” within “funder_name”. For example, this deposit excerpt has the funder ”National Science Foundation” with its corresponding funder identifier in the funding Registry of “http://dx.doi.org/10.13039.10000001":

<fr:assertion name="funder_name">National Science Foundation <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039.10000001</fr:assertion>
</fr:assertion>

A relationship betwen a single “funder_name” and/or ”funder_identifier” and an “award_number” is established by including assertions with a <fr:program>. In this example, funder “National Institute on Drug Abuse” with funder identifier “http://dx.doi.org/10.13039/R01ZDA" are associated with award number “JQY0937263”:

<fr:program name="fundref"> <fr:assertion name="funder_name">National Institute on Drug Abuse <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039/R01ZDA</fr:assertion> </fr:assertion> <fr:assertion name="award_number">JQY0937263</fr:assertion> </fr:program>

If multiple funder and award combinations exist, each combinaton should be deposited within a “fundgroup” to ensure that the award number is associated with the appropriate funder(s). In this example, two funding groups exist: 1. Funder “National Science Foundation” with funder identifier “” is associated with award numbers “CBET-106” and “CBET-106”, and 2. Funder “Basic Energy Sciences, Office of Science, U.S. Department of Energy” with funder identifier “http://dx.doi.org/10.13039/100006151" is associated with award number “1245-ABDS”.

<fr:program name="fundref"> <fr:assertion name="fundgroup"> <fr:assertion name="funder_name">National Science Foundation <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039/00000001</fr:assertion> </fr:assertion> <fr:assertion name="award_number">CBET-106</fr:assertion> <fr:assertion name="award_number">CBET-7259</fr:assertion> </fr:assertion>

<fr:assertion name="fundgroup"> <fr:assertion name="funder_name">Basic Energy Sciences, Office of Science, U.S. Department of Energy <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039/100006151</fr:assertion> </fr:assertion> <fr:assertion name="award_number">1245-ABDS</fr:assertion> </fr:assertion> </fr:program>

Items with multiple funder names but no award numbers may be deposited without a fundgroup.

At minimum a funding data deposit must contain a “funder_name” and ”funder_identifier” assertion. Deposits with just an “award_number” assertion are not allowed. A “funder_name”, “funder_identifier”, and “award_number” should be included in deposits whenever possible. If the funder name cannot be matched in the Registry you may submit funder_name only and the funding body will be reviewed and considered for addition to the official Registry. Until it is added to the Registry the deposit will not be considered a valid funding record and will not appear in funding Search or the Search API.

As demonstrated in Example #3, items with several award numbers associated with a single funding organization should be grouped together by enclosing the “funder_name”, “funder_identifier”, and award_number(s) within a “fundgroup” assertion.

Some rules will be enforced by the deposit logic, including:

Nesting of the <fr:assertion> elements: the schema allows infinite nesting of the assertion element to accommodate nesting of an element within itself. Deposit code will only allow 3 levels of nesting (with attribute values of “fundgroup”, “funder_name”, and “funder_identifier”)
Values of different <fr:assertion> elements: “funder_name”, “funder_identifier”, and “award_number” may have deposit rules imposed
Only valid funder identifiers will be accepted: the “funder_identifier” value will be compared against the Open Funder Registry file. If the funder_identifier is not found, the deposit will be rejected.

Deleting or updating funding metadata

If funding metadata is incorrect or out of date, it may be updated by redepositing the metadata. Be sure to redeposit all available metadata for an item, not just the elements being updated.

Funding metadata may be deleted by redepositing an item with an empty <fr:program name=“fundref”> element:

Deleting non-Crossmark funding metadata: + show/hide example

... <publication_date media_type="print"> <year>2011</year> </publication_date> <pages> <first_page>15</first_page> </pages> <fr:program name="fundref" /> <doi_data> <doi>10.5555/cm_test_1.1</doi> <resource>https://www.crossref.org/crossmark/index.html</resource> </doi_data> </journal_article>

Deleting Crossmark funding metadata: + show/hide example

<crossmark> <crossmark_version>1</crossmark_version> <crossmark_policy>10.5555/cm_1</crossmark_policy> <crossmark_domains> <crossmark_domain><domain>www.crossref.org</domain></crossmark_domain> </crossmark_domains> <crossmark_domain_exclusive>true</crossmark_domain_exclusive> <updates> <update type="correction" label="Correction" date="2011-04-10">10.5555/cm_test2.1</update> <update type="retraction" label="Retraction" date="2011-04-12">10.5555/cm_test2.2</update> </updates> <custom_metadata> <assertion name="received" label="Received" group_name="publication_history" group_label="Publication History">2011-04-12</assertion> <fr:program name="fundref" /> </custom_metadata> </crossmark>
A DOI may be updated without resubmitting funding metadata, previously deposited funding metadata will remain associated with the DOI.
Submitting an empty Crossmark tag (<crossmark />) will delete all funding data for the item.

Examples

1. Funding Organization information within a Crossmark deposit: The <fr:program> element captures funder data as <custom_metadata> within the <crossmark> element.

<crossmark> <crossmark_version>1</crossmark_version> <crossmark_policy>10.5555/crossmark_policy</crossmark_policy> <custom_metadata> <fr:program name="fundref"> <fr:assertion name="funder_name">National Science Foundation <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039/100000001</fr:assertion> </fr:assertion> <fr:assertion name="award_number">psychoceramics-1152342</fr:assertion> </fr:program> </custom_metadata> </crossmark>

2. Funding Organization information outside of Crossmark: The <fr:program> element captures funding data, it should be placed before the <doi_data> element. This deposit contains minimal funding data - one “funder_name” or one “funder_identifier” must be present; both are recommended.

<fr:program name="fundref"> <fr:assertion name="funder_name">National Science Foundation <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039/100000001</fr:assertion>

</fr:assertion>

</fr:program>

3. One funding organization, two grant numbers: This example contains one funder_name and one funder_identifier. Note that the funder_identifier is nested within the funder_name assertion, establishing “http://dx.doi.org/10.13039.100000001" as the funder identifier for funder name “National Science Foundation.” Two award numbers are present.

<fr:program name="fundref"> <fr:assertion name="funder_name">National Science Foundation <fr:assertion name="funder_identifier">http://dx.doi.org/10.13039/100000001</fr:assertion> </fr:assertion> <fr:assertion name="award_number">CBET-106</fr:assertion> <fr:assertion name="award_number">CBET-7259</fr:assertion> </fr:program>

4. Multiple Funding Organizations and grant numbers: This example contains two funder_name/identifiers and two award_numbers for each funder. Each funding organization is within its own “fundgroup”.

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Multiple Resolution Overview

Crossref’s Multiple Resolution service allows multiple URLs to be assigned to a single DOI. The DOI resolves to an interim page, which presents a list of link choices to the end user. Publishers most commonly implement Multiple Resolution for content with co-hosting agreements.

Multiple Resolution operates by directing the DOI to a service hosted by Crossref which uses a HTML template to present a branded page (known as an interim page) to the end user. Templates may be assigned on a title or prefix basis (e.g. a unique template per publication title, or one template for all titles associated with a given prefix).

Example interim page: + show/hide or http://dx.doi.org/10.1177/152216280100400206

Response page (from http://dx.doi.org/10.1177/152216280100400206)

Multiple Resolution details

The current version of Crossref’s Multiple Resolution service has been active since May 2008. The pilot version has been discontinued. Differences between the pilot and production version are described here.

Passing parameters

Mon, 01 Jan 0001 00:00:00 +0000

Passing parameters

Parameter passing permits data placed on an outbound DOI link to pass along to the target publisher. There are two procedures for passing parameters: The first uses an undocumented feature of the DOI resolver while the second is a robust implementation based on OpenURL structured to prevent name collisions that would result in the loss of data.

Procedure 1

For very limited situations where parameter passing is needed, you can use the name-value pair called “urlappend”. You can construct outbound links by placing parameter values in this single URL variable. However, before constructing the link, you must know if the registered URL for the DOI already has parameters.

For example, suppose DOI 10.5555/unique_doi_060103-01 has no parameters on its registered URL. You can then pass parameters as follows:

http://dx.doi.org/10.5555/unique_doi_060103-01?urlappend=%3fpassed_param=

DOI 10.5555/unique_doi_060103-01 does have parameters on its registered URL , passed parameter are added as follows:

http://dx.doi.org/10.5555/unique_doi_060103-01?urlappend=%26passed_param=

Because the urlappend function is primitive, you must insert the correct character—either a question mark (%3F) or an ampersand (%26)—before the name-value pair information you want to pass. In addition, if the target’s publisher is not be expecting incoming parameters, the values placed in urlappend may conflict with names of parameters already on the registered URL.

Procedure 2

This more robust solution based on OpenURL is a bit more complicated, but it has several advantages:

It works whether or not the DOI’s registered URL already has parameters.
It prevents parameter name collisions.
It lets the recipient of the link (the host of the target) control whether it receives passed parameters.
It establishes a common vocabulary for passed parameters, reducing the need for bi-lateral coordination.

OpenURL 1.0 defines a set of parameters to use when conveying information in a hyperlink. Procedure 2 depends on two of these parameters—rft_dat and rfr_dat—to act as wrappers for both the passed parameters and the existing parameters on the DOI’s registered URL. Parameter rft_dat (referent data) contains the entire registered URL’s parameter set as a nested string. Parameter rfr_dat (referrer data) contains another nested string with the information the source wants to pass to the target. Data inside the rfr_dat should conform to the controlled vocabulary described in the Parameter Passing white paper (PDF). Because the DOI’s registered URL parameters are safely nested inside rft_dat, parameter passing also forwards any non-OpenURL parameters found on the source link to the target.

Crossref strongly encourages the use of rfr_dat due to the controlled vocabulary.

For example, this in-bound link:

http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01&rfr_dat=rfr_dat=cr_setver=01&cr_pub=Source Publisher&cr_work=Source Journal Title&cr_src=SRC-NAME

is combined with the registered URL:

http://www.crossref.org/paramEcho?param=done&param2=two

to create the following outbound link:

http://www.crossref.org/paramEcho?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01&rft_dat=param1=done&param2=two&rfr_dat=rfr_dat=cr_setver=01&cr_pub=Source Publisher&cr_work=Source Journal Title&cr_src=SRC-NAM

For readability, this example is not shown in encoded form. If they were, the rft_dat portion would look like this: rft_dat=param1%3Ddone%26param2%3Dtwo.

More Examples

Example 1

This link uses a DOI without parameter passing:

http://dx.doi.org/10.5555/unique_doi_060103-01

The target system would receive the following incoming information:

(name) param1 (value) one (name) param2 (value) two —————–Using request.getParameter()

where the values of param1 and param2 are part of the URL registered for the DOI.

Example 2

This link uses the same DOI with parameter passing:

http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01&rfr_data=stuff%3dgood

The source of the link wants to send the name-value pair of stuff=good to the target system. The param1 and param2 variables are still passed to the target, as shown here, but they are wrapped inside the rft_dat parameter:

(name) url_ver (value) Z39.88-2003 (name) rft_id (value) doi:10.5555/unique_doi_060103-01 (name) rfr_data (value) stuff%3dgood Nested Parameters (name) stuff (value) good (name) rft_dat (value) param1%3Done%26param2%3Dtwo Nested Parameters (name) param1 (value) one (name) param2 (value) two —————–Using request.getParameter()

The data stuff=good is also passed to the target inside the rfr_dat parameter. This demonstrates good practice by avoiding name conflicts.

Example 3

This link demonstrates that any top-level paramater will also be passed to the target, but it will not be wrapped in any OpenURL containers:

http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01&rfr_data=stuff%3dgood&santa=claus

In this case, the name-value pair santa=claus is appended to the link in a way that is not consistent with (but no explicitly prohibited by) the OpenURL specification. The target receives this data:

(name) url_ver (value) Z39.88-2003(name) rft_id (value) doi:10.5555/unique_doi_060103-01 (name) rfr_data (value) stuff%3dgood Nested Parameters (name) stuff (value) good (name) santa (value) claus (name) rft_dat (value) param1%3Done%26param2%3Dtwo Nested Parameters (name) param1 (value) one (name) param2 (value) two —————–Using request.getParameter()

Example 4

This link shows how the OpenURL based parameter passing handles potential conflicts in parameter names:

http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01&param1=five

In this case, the variable param1 is passed to the target twice:

(name) url_ver (value) Z39.88-2003 (name) rft_id (value) doi:10.5555/unique_doi_060103-01 (name) five?url_ver (value) Z39.88-2003 (name) rft_id (value) doi:10.5555/unique_doi_060103-01 (name) param1 (value) five (name) rft_dat (value) param1%3Done%26param2%3Dtwo Nested Parameters (name) param1 (value) one (name) param2 (value) two —————–Using request.getParameter()

Here, the param1 nested inside rft_dat is known to be the one registered with the DOI’s URL.

If, on the other hand, you used the primitive urlappend function instead, as shown here:

http://dx.doi.org/10.5555/unique_doi_060103-01?urlappend=%26param1=five

the target wouldn’t be able to tell which value of param1 came from the DOI or from the source link:

(name) param1 (value) one (name) param2 (value) two (name) param1 (value) five —————–Using request.getParameter()

PatientInform

Mon, 01 Jan 0001 00:00:00 +0000

Background:

Patient INFORM is a joint initiative between publishers and voluntary health organizations (VHO) to make the scholarly literature on certain medical topics more accessible to the general public. Participating VHOs will author summary articles to be hosted on the VHO Web site that provide contextual information about the particular subject. The summary will also contain a link to a targeted full text article residing on various publisher’s Web sites. End users reading the VHO summary article will be given clear and free access to the full text of the target article without the need for any additional login procedure.

The Registration Form – basic step-by-step:

Each article pair (VHO summary and the corresponding publisher full text article) must be registered using this form. Complete field descriptions and usage are given below. The basic step-by-step process is as follows:

Select your VHO from the drop down list and enter the VHO password (one password per VHO organization)
Enter the email address of a VHO staff member who can address problems with this summary article
Enter the URL of the summary article as hosted on the VHO Web site (this field partially auto-fills for certain VHOs)
Enter the DOI or URL of the publisher’s article. DOIs are preferred, if you don’t know the DOI use the lookup tool at the bottom of the registration form (URL must be of the form http://some.address.domain/full/file/path/filename.html, DOIs should be entered as 10.1234/the-suffix-text). NOTE: to link to a DOI from your Web page you will build a URL as follows: http://dx.doi.org/the-doi
Fill in the optional fields. Complete titles and descriptions are strongly encouraged as these will help find and manage article pairs.
Hit the Save button

Submitting the form will produce one of two outcomes.

A notice will be displayed stating that everything went Ok. In this case the article pair has been registered and the publisher was notified. Access to the publisher’s full text article will begin almost immediately
The publisher could not be contacted. In this case the article pair has been registered, however, the publisher could not be immediately contacted. Email notifications will go to Patient INFORM staff who will manually contact the publisher. Access to the publisher’s full text article will not be enabled until this situation is rectified. The email address given in the form is important for Patient INFORM staff to use in contacting the VHO on this matter.

The Registration Form – field details:

URL of Summary Item: The complete Web address of the summary article hosted on the VHO Web site. This address is very important for use by the publisher in granting access to the full text article. Only readers coming from this page will be given access. Please contact your VHO Web site administrator if you don’t know what to fill in here.

Target Article: The location of the publisher article, DOIs are preferred. DOIs are simple identifiers for articles that can be used instead of a URL. They are more reliable than URLs since if the article is moved the DOI will always find it. Use the DOI lookup function at the bottom of the registration form to find a DOI.

24-hour delay: You may be registering an article pair before the summary article is actually posted to the VHO Web site. Since publishers will be linking back to the VHO summary article this simple option tells the publisher to not link back for at least 24 hours. This prevents broken links from the publisher back to the VHO. If you know the VHO summary article will not be available within 24 hours, please hold off registering the article pair.

Referring URL: In certain cases a VHO may want user to link to the publisher from an interim page other than the summary article. This URL can be used for that purpose. Please contact your VHO Web site administrator. Typically this field will be left empty if the users go directly from the summary to the publisher’s article.

Title: The title of the summary article hosted on the VHO Web site

Description: A description of the summary article’s topic, possibly making mention of the publisher’s full text article.

VHO Author: Full name of the summary article’s author.

The DOI lookup tool:

If you only know basic bibliographic information about the publisher’s article you can search for it DOI. Simply enter as much information as you can and select “Lookup” (note: you must supply either the author’s last name or the starting page for the article).

In the results you may click on the DOI link to view the article, which will open in a separate window. If this is the target article, click “Use This DOI” to auto-fill the DOI into the appropriate field at the top of the registration form.

PatientInform

Mon, 01 Jan 0001 00:00:00 +0000

Patient INFORM is a joint initiative between publishers and voluntary health organizations (VHO) to make the scholarly literature on certain medical topics more accessible to the general public. Participating VHOs will author summary articles to be hosted on the VHO Web site that provide contextual information about the particular subject. The summary will also contain a link to a targeted full text article residing on various publisher’s Web sites. Visitors reading the VHO summary article will be given clear and free access to the full text of the target article without the need for any additional login procedure.

In order for this access control process to work, publishers need to be set up to receive the identity of the target articles and the source URL from which VHO readers will be coming. In addition, publishers need information about where on the VHO Web site to return users or to send users who come across the publisher article by means other than the VHO’s site.

Two services make this data available to the publishers:

An instant notification called the ‘piPush’ or ‘pi(patientINFORM)Push’
A batch listing of all registered articles formatted as an RSS 1.0 XML feed

piPush Instant Notification

To utilize the notification method, publishers must implement a Web service to be called at http://publisher.address/piPush/. Upon registration of an article by a VHO, the registration form will attempt to contact this service to pass along the details of the registration. The address for the service is determined using a process of elimination based on the type of link to the publisher’s target article provided by the VHO.

If the link is a simple URL use the machine address of the URL (e.g for a target URL http://www.publisher-site.com/article-location/article-name.html the notification will go to http://www.publisher-stie.com/piPush?setId=xxx)
If the link is a DOI
1. Determine the owner of the DOI
2. If the publisher has provided Crossref an address for their piPush receiver use that address
3. Else, retrieve the URL for this DOI and extract the address as was done in option #1 above

Note: option 2b is provided for when a publisher needs to direct their piPush notifications to an address not related to their content Web hosting address. If this is the case, please contact support@crossref.org.

The piPush notification is implemented as an HTTP POST with the following parameters (first four are mandatory, others are optional):

setId : a unique integer ID given to each article pair registered
vhoId : a number identifying the VHO (1=ADA,2=ACS,3=AHA)
target: a URL or DOI to the target article (http:// or doi:10.xxxx/)
cover-sheet: the URL of the summary article page on the VHO Web site (this may be the referring URL, but is always considered the return URL)
delay: boolean. When true linking back to the VHO should be postponed for 24 hours
return : the referring URL, if different than the cover-sheet URL (some VHOs may channel all outbound links from their site through a single ‘departure’ page)
- (note: the name ‘return’ is retained for functional compatibility, however the semantics are as described here)
title: as provided by the VHO
description: as provided by the VHO
delete: will equal true if this record has been deleted
test: will equal true if this record is coming from the test system

RSS Feed Notification

In addition to the piPush notification, Crossref will post updates once every 6 hours to an RSS 1.0 formatted XML file containing a listing of all articles registered for the current month. Listings for prior months will remain available.

Link to the latest version of the registry listing => http://www.crossref.org/PIrss/piRegistry.xml
Link to any given month of the registry listing => http://www.crossref.org/PIrss/piRegistryYYYYMM.xml

A publisher using this method of notification needs to check the feed for relevant requests so that links can be opened manually in a timely way.

An example of the RSS file is shown below:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns:pi="http://www.patientINFORM.org/registry/"xmlns="http://purl.org/rss/1.0/">  <channel rdf:about="http://www.patientINFORM.org/PIregistry"> <title>PatientINFORM Article Registry for May 2005</title> <link>http://www.patientINFORM.org/PIregistry</link> <items> <rdf:Seq> <rdf:li rdf:resource="http://www.patientINFORM.org/PIregistry?viewSetId=1234"/> <rdf:li rdf:resource="http://www.patientINFORM.org/PIregistry?viewSetId=1235"/> </rdf:Seq> </items> </channel>  <item rdf:about="http://www.patientINFORM.org/PIregistry?viewSetId=1234"> <title>The title Of the VHO summary item</title> <link>http://www.vho.org/a_summary_article.com</link> <description>A description of the VHO summary article</description> <pi:target>doi:10.5555/mrtestdoi</pi:target> <pi:referringURL>http://some.address.org/some_path.html</pi:referringURL> <pi:action>register</pi:action> <pi:pubPrefix>10.XXXX</pi:pubPrefix> <dc:publisher>The publisher name</dc:publisher> <dc:creator>VHO Name</dc:creator> <dc:identifier>set ID</dc:identifier> <dc:date>2005-04-30T12:52:10-4:00</dc:date> </item> <item rdf:about="http://www.patientINFORM.org/PIregistry?viewSetId=1235"> <title>The title Of the VHO summary item</title> <link>http://www.vho.org/a_summary_article.com</link> <description>A description of the VHO summary article</description> <pi:target>doi:10.5555/mrtestdoi</pi:target> <pi:referringURL>http://some.address.org/some_path.html</pi:referringURL> <pi:action>register</pi:action> <pi:pubPrefix>10.XXXX</pi:pubPrefix> <dc:publisher>The publisher name</dc:publisher> <dc:creator>VHO Name</dc:creator> <dc:identifier>set ID</dc:identifier> <dc:date>2005-04-30T12:52:10-4:00</dc:date> </item> </rdf:RDF>

PatientInform: publisher testing

Mon, 01 Jan 0001 00:00:00 +0000

Publisher Testing of the patientINFORM piPush Function

To facilitate rapid deployment of “piPush” receivers by patientINFORM participating publishers, Crossref has set up a development copy of the PIregistry form used by the VHO’s. You may refer to the standard form instructions for information on the fields and their uses.

The development form is located at: http://www.crossref.org/testPIregistry

The development form works exactly the way the production form works except for 3 functions that are altered to help the publisher test their systems.

The development copy has all the VHO user’s accounts set to use one password and that is ‘tryme”. This allows the publisher to act as a VHO to register items for testing that point to their own content.
The development copy internally executes all ‘piPush’ http connections with the “test” parameter set to “true”. So ‘piPush’ POSTs from this system and the production system differ ONLY by that parameter.
The development copy uses a separate table to override where ‘piPush’ transactions are sent for DOI registrations. This is useful if you want to set up a particular location for your piPush receiver for testing. See the item 2b in the Publisher Implementation instructions for more on this override feature.

Here is a sample process a publisher might go through to implement this service:

Publisher ABC Publishing signs up to participate in patientINFORM.
ABC Publishing has their web programmer put together a http servlet that deploys under the name piPush on their server at http://www.abcpublishng.com. Internally, that servlet accepts HTTP Posts, processes the parameterized fields for the fields setId, vhoId, target, cover-sheet, delay, return, title, description, delete, test as noted in Patient Inform: Publisher Implementation, writes whatever handle is required into their internal system to turn on access for their content based on the return URL data, and return a 200 to the HTTP requester if all goes well or some error (403, 404, 500) if it does not.
The publisher’s developer then contacts Crossref (currently Jon Stark jstark@crossref.org) to ask that the development system be set up to send all test piPushes for their prefix (e.g.,10.9999) to http://www.abcpublishing.com/piPush/.
Once step C is completed, the developer proceeds to the test form at http://www.crossref.org/testPIregistry and acts as a VHO to register an article that points to their own target publication (target set to 10.9999/test-article) and then clicks save to initiate the piPush.
The developer can then see the response the PIregistry gets as well as monitoring their own piPush application to see what comes through and test their application’s behavior.
Once all testing is done and the publisher is ready, they can chose to inform Crossref (email jstark@crossref.org) of the final, official domain they want to redirect piPush transactions to (www.abcpublishing.com) or set up their piPush application at the domain their content is hosted at by default (i.e. 10.9999/abcDois all look up to www.abcpublishing.com/blah/blah/abcDois… and piPush answers at www.abcpublishing.com/piPush/ then no override is required).

Platform transfer

Mon, 01 Jan 0001 00:00:00 +0000

Updating DOIs during platform transfers

Most updates occur on a title-by-title basis. Occasionally members need to update DOI URLs for all their content. In practice this works like a URL-only update, but since multiple titles and sometimes prefixes are involved, migrations can be complex. DOIs are updated at a rate of 1 DOI per second. Massive updates (>1,000,000 DOIs) may take up to a week to complete, so plan accordingly.

Updating URLs

The primary need is for DOI URLs to be redirected from one URL to another. This can be done using a URL-only update. When updating DOIs involving multiple titles and prefixes, be aware of the following when updating URLs:

The fromPrefix and toPrefix are the prefix owning the DOIs to be updated. Only one prefix is allowed per update file.
Update files should not exceed 2 MB. If necessary, split the update into multiple files. Each file should contain a header.
If needed, Crossref can provide members with a list of the DOIs and URLs deposited to our system.

Publishers may also update URLs by redepositing metadata. Use the Deposit Harvester to retrieve metadata that has been deposited with Crossref.

Publication IDs

Mon, 01 Jan 0001 00:00:00 +0000

Publication IDs

Every publication in the Crossref system is assigned a unique publication ID. These are used mostly for internal purposes, but may be useful when retrieving data in bulk or identifying a specific title.

Publication IDs may be retrieved via the following:

OAI-PMH

An OAI-PMH ListSets request will return titles and publication IDs for journals, books, conference proceedings, and series-level data:

http://oai.crossref.org/OAIHandler?verb=ListSets

http://oai.crossref.org/OAIHandler?verb=ListSets&set=B

J (journal) is the default set, set=B must be specified to retrieve book or conference proceeding titles, S for series-level titles. Sets may be further limited by publisher prefix, details are available in Using OAI-PMH.

The publication ID is listed within the <setspec> element, after the set and publisher prefix. For example, within the following set, 24 is the publication ID for Journal of Clinical Psychology:

<set>

J:10.1002:24

</setSpec>

Journal of Clinical Psychology

</setName>

</set>

Browsable title list

The Browsable title list includes the publication ID next to each title in the search results, select to reveal the ID.

For most purposes, publication IDs are always preceded by the publication type (J, B, or S)

Publication dates and deposit fees

Mon, 01 Jan 0001 00:00:00 +0000

Publication dates and deposit fees

Current deposit fees are listed on the Crossref website

DOI deposit fees are determined by the content type and publication date included in a deposit, with backfile deposits being charged at a lower rate. The publication year included in the initial DOI metadata submission determines whether or not a DOI is considered a Current Year (CY) or Back Year (BY) DOI. The Crossref schema supports deposit of both an online and print publication dates. For individual items, when both online and print publication years are present, the fee charged is determined by the print year. If a print year is not included in the deposit, the online publication year is considered.

When depositing journals be aware that each individual item is considered separately, regardless of the publication year included at the journal volume or issue level. For example, a deposit including both a print publication date of 1990 and an online date of 2013 at the issue level and only an online publication date of 2013 at the article level will be considered a current year deposit. If the print date of 1990 is included at the article level, the back year fee will be charged.

Issue Year Article Year Fee level

DOI1 2013 (online), 1971 (print) 2013 (online), 1971 (print) BY rate DOI2 2013 (online), 1971 (print) 2013 (online), no print date CY rate DOI3 2013 (online), no print 2013 (online), 1971 (print) BY rate DOI4 2013 (online), no print 1971 (print) BY rate

: Example: Fees charged by publication year type

Publisher info APIs

Mon, 01 Jan 0001 00:00:00 +0000

Publisher info APIs

Publisher name and prefix:retrieve a list of publisher names and associated prefixes:

https://doi.crossref.org/getPrefixPublisher

Prefix by deposit account:retrieve a list of prefixes associated with a deposit account:

https://doi.crossref.org/info?usr=&pwd=<PASSWORD>&rtype=prefixes

Quarterly deposit report

Mon, 01 Jan 0001 00:00:00 +0000

Quarterly deposit report

A .csv file listing back year, current year, and update DOI deposit counts by quarter can be generated upon request. Contact support@crossref.org.

Query error messages

Mon, 01 Jan 0001 00:00:00 +0000

Error messages for malformed queries

Possible errors returned by malformed or insufficient queries include:

Either first page or author must be supplied.
Either ISSN or Journal title must be supplied.
unreasonable DOI found
* an ‘unreasonable DOI’ does not follow the expected DOI format (10.XXXX/yyy..) and/or exceeds 200 characters.
Piped Query must contain either 9 (for journals) or 11 (for books/conference proceedings) pipes.
Either ISSN/ISBN or Series/Volume title must be supplied.

Query results

Mon, 01 Jan 0001 00:00:00 +0000

Query results

Crossref supports a number of formats for query results:

UNIXSD: (corresponding schema) contains as-deposited metadata and meta-metadata for the DOI (information about the DOI such as current prefix owner, date of last update, cited-by count).

UNIXREF: (corresponding schema) UNIXREF returns the exact data submitted by the publisher of the DOI.

XSD_XML: returns very basic citation metadata. XSD_XML is currently the default format. This format may be deprecated in the future.

A list of DOIs by title may be retrieved using format=doilist, details are available here.
References for a given article (if deposited) are only included in results when permitted by the DOI owner. References are always included when querying for content you own.

Query samples

Mon, 01 Jan 0001 00:00:00 +0000

XML Query Samples

Book queries: See Querying for books

Cited-by queries

An XML query to obtain a list of cited-by articles (forward links): + show/hide example

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/qschema/2.0 http://www.crossref.org/qschema/crossref_query_input2.0.xsd">

<head> <email_address>your@email.com</email_address> <doi_batch_id>fl_001</doi_batch_id> </head> <body> <fl_query alert="false" > <doi>10.1051/forest:19990308</doi> </fl_query> </body> </query_batch>

This query can only be performed by the owner of the cited article.

Controlling query result XML

Crossref query results can be retrieved in several formats (see Query Results). By default the XSD_XML format will only contain basic bibliographic metadata. Setting expanded-results to TRUE will also return the article title.

This example shows use of this property along with multiple hits: + show/hide example

Query:

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address>hisham@atypon.com</email_address> <doi_batch_id>Sample multi resolve</doi_batch_id> </head> <body> <query key="mutliResolve1" enable-multiple-hits="true" expanded-results="true"> <issn>0360-3016</issn> <volume>54</volume> <issue>2</issue> <first_page>215</first_page> <year>2002</year> </query> </body> </query_batch>

Results:

<crossref_result version="2.0" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 http://www.crossref.org/qrschema/crossref_query_output2.0.xsd"> <query_result> <head> <email_address>hisham@atypon.com</email_address> <doi_batch_id>Sample multi resolve</doi_batch_id> </head> <body> <query key="mutliResolve1" status="multiresolved" fl_count="0"> <doi type="journal_article">10.1016/S0360-3016(02)03429-6</doi> <issn type="print">03603016</issn> <journal_title> International Journal of Radiation Oncology*Biology*Physics</journal_title> <author>KIM</author> <volume>54</volume> <issue>2</issue> <first_page>215</first_page> <year>2002</year> <publication_type>full_text</publication_type> <article_title> Potential radiation sensitizing effect of SU5416 by down-regulating the COX-2 expression in human lung cancer cells </article_title> </query> <query key="mutliResolve1" status="multiresolved" fl_count="0"> <doi type="journal_article">10.1016/S0360-3016(02)03428-4</doi> <issn type="print">03603016</issn> <journal_title> International Journal of Radiation Oncology*Biology*Physics </journal_title> <author>WILLIAMS</author> <volume>54</volume> <issue>2</issue> <first_page>215</first_page> <year>2002</year> <publication_type>full_text</publication_type> <article_title> Effect of the administration of lovastatin on the development of pulmonary fibrosis following whole lung irradiation in a mouse model </article_title> </query> </body> </query_result> </crossref_result>

The system will return no DOIs if an ambiguity exists. Setting enable-multiple-hits to “true” instructs the system to return the list of DOIs.

Searching all authors

Normally the author name supplied in a query must be that of the article’s ‘first’ author. First author is an optional designation made by the publisher when depositing a DOI’s metadata. Articles deposited without a ‘first’ author designation handicap queries that depend on author (e.g. do not supply a page number) In an XML query there is a property called search-all-authors which forces the process to examine all authors associated with the article.

This example shows a query that would not return any results if this feature were not used: + show/hide example

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address>support@crossref.com</email_address> <doi_batch_id>Sample multi resolve</doi_batch_id> </head> <body> <query key="mutliResolve1" enable-multiple-hits="false"> <journal_title>Advances in Applied Probability</journal_title> <author search-all-authors="true">Weil</author> <volume>33</volume> <year>2001</year> </query> </body> </query_batch>

Reverse metadata query

Retrieve metadata for a DOI: + show/hide example

Query: Sample XML

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address>hisham@atypon.com</email_address> <doi_batch_id>Sample multi resolve</doi_batch_id> </head> <body> <query key="mykey" expanded-results="true"> <doi>10.1006/jmbi.2000.4282</doi> </query> </body> </query_batch>

Result:

Querying for books

Mon, 01 Jan 0001 00:00:00 +0000

Querying for books

Book chapter query: a query which will return the DOI for a single chapter in the specific title: + show/hide example

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address>hisham@atypon.com</email_address> <doi_batch_id>SomeTrackingID2</doi_batch_id> </head> <body> <query key="MyKey1" enable-multiple-hits="false"> <author>Casteilla</author> <volume>155</volume> <first_page>1</first_page> <year>2001</year> <isbn>1-59259-231-7</isbn> <volume_title>Adipose Tissue Protocol</volume_title> </query> </body> </query_batch>

Searching for individual chapters within a book may also be done by using just the author name and chapter title (author name is optional but should be included for better results): + show/hide example

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address>hisham@atypon.com</email_address> <doi_batch_id>SomeTrackingID2</doi_batch_id> </head> <body> <query key="MyKey1" enable-multiple-hits="false"> <author>Casteilla</author> <article_title>Choosing an Adipose Tissue Depot for Sampling </article_title> </query> </body> </query_batch>

Book title query: The deposit for this book also created a DOI for the book itself which can be found with a query containing the book’s editor: + show/hide example

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address>hisham@atypon.com</email_address> <doi_batch_id>SomeTrackingID2</doi_batch_id> </head> <body> <query key="MyKey1" enable-multiple-hits="false"> <author> Ailhaud</author> <volume>155</volume> <first_page>1</first_page> <year>2001</year> <isbn>1-59259-231-7</isbn> <volume_title>Adipose Tissue Protocol</volume_title> </query> </body> </query_batch>

Book title query without author:Many title-level book DOIs do not have author information deposited. If you do not have author information to include in your query or you are querying for an authorless book, for best results your query should instruct the system to ignore author by setting the author match attribute to null. + show/hide example

<?xml version = "1.0" encoding="UTF-8"?> <query_batch xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xmlns="http://www.crossref.org/qschema/2.0"xsi:schemaLocation="http://www.crossref.org/qschema/2.0 http://www.crossref.org/qschema/crossref_query_input2.0.xsd"> <head> <email_address>test@crossref.org</email_address> <doi_batch_id>test</doi_batch_id> </head> <body> <query key="555-555" > <isbn>9780387791456</isbn> <journal_title>Ordinary and Partial Differential Equations</journal_title> <year>2009</year> <author match="null"/> </query> </body> </query_batch>

Querying with XML

Mon, 01 Jan 0001 00:00:00 +0000

Querying with XML

Crossref maintains an XSD schema which defines the structure and context for the XML tags used in formulating a query. The latest schema file is crossref_query_input2.0.xsd (documentation). Many query elements have optional properties that control how the query is executed by the system- these controls are explained in detail in the topic Controlling query execution.

The following is an example of a journal XML query:

<?xml version="1.0"?>

<head>

<email_address>support@crossref.org</email_address>

<doi_batch_id>ABC_123_fff</doi_batch_id>

</head>

<body>

<query key="1178517" enable-multiple-hits="false" forward-match="false">

<issn match="optional">15360075<issn

<journal_title match="exact">American Journal of Bioethics</journal_title>

<author match="fuzzy" search-all-authors="false">Agich</author>

<volume match="fuzzy">1</volume>

<issue>1</issue>

<first_page>50</first_page>

<year>2001</year>

<article_title>The Salience of Narrative for Bioethics</article_title>

</query>

</body>

</query_batch>

XML queries can be sent into the Crossref system using synchronous and asynchronous techniques. For further information please see the section on interfacing with the Crossref system.

As a general rule, including all available metadata in a query produces best results, but querying for title-level book DOIs vs. book chapter DOIs may require special attention- see Querying for books.

Querying with formatted citations

Mon, 01 Jan 0001 00:00:00 +0000

Querying with formatted citations

Formatted citations are sometimes referred to as “plain text references.” For example, an APA formatted citation for the DOI 10.1038/nclimate1398 is:

Hungate, B. A., & Hampton, H. M. (2012). Ecosystem services: Valuing ecosystems for climate. Nature Climate Change, 2(3), 151-152. http://dx.doi.org/10.1038/nclimate1398

Crossref has two interfaces that can be used for making formatted citation queries:

Simple Text Query (STQ): tool which allows a user to cut-and-paste references into an interactive form and receive instant results or to upload a text file and receive HTML format results via email.

Crossref API: supports two options:

HTTP Get:When enabled, this option accepts XML queries that may contain formatted citations. + show/hide example
http://doi.crossref.org/servlet/query?usr=<USERNAME>&pwd=<PASSWORD>&format=unixref&qdata=<?xml version = "1.0" encoding="UTF-8"?><query_batch xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xmlns="http://www.crossref.org/qschema/2.0" xsi:schemaLocation="http://www.crossref.org/qschema/2.0 http://www.crossref.org/qschema/crossref_query_input2.0.xsd"><head><email_address>your@email.org</email_address><doi_batch_id>01032012</doi_batch_id></head><body><query key="q1" enable-multiple-hits="true"><unstructured_citation>Hungate, B. A., & Hampton, H. M. (2012). Ecosystem services: Valuing ecosystems for climate. Nature Climate Change, 2(3), 151-152.</unstructured_citation></query></body></query_batch>
HTTP Post: A file upload service which accepts an XML file and returns results via email. This option is only available to Crossref members and affiliates. + show/hide example
<?xml version = "1.0" encoding="UTF-8"?> <query_batch xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xmlns="http://www.crossref.org/qschema/2.0" xsi:schemaLocation="http://www.crossref.org/qschema/2.0 http://www.crossref.org/qschema/crossref_query_input2.0.xsd"> <head> <email_address>your@email.org</email_address> <doi_batch_id>01032012</doi_batch_id> </head> <body> <query key="q1" enable-multiple-hits="true"> <unstructured_citation>Hungate, B. A., & Hampton, H. M. (2012). Ecosystem services: Valuing ecosystems for climate. Nature Climate Change, 2(3), 151-152.</unstructured_citation> </query> <query key="q2" enable-multiple-hits="true"> <unstructured_citation>Ewert, F. (2012). Adaptation: Opportunities in climate change? Nature Climate Change, 2(3), 153-154. doi:10.1038/nclimate1426</unstructured_citation> </query> </body> </query_batch>

Using HTTP to Query, Using HTTP to POST Files (Upload)

Crossref has two distinct servicing technologies (mutually exclusive) that support these interfaces: eXtyles RefXpress (a tool licensed from Inera, Inc.), and Formatted Citation Search (FCS).

eXtyles RefXpress

RefXpress is a powerful citation parser, meaning citations are broken up into their parts (publication title, author, volume, issue, page, publication date, etc.). These parts can then easily be transformed into an XML query. Usage limits are in place, see Use Options below.

Formatted Citation Search

This option is a full-text-search technique- citations are not parsed into parts. Instead, the citation as a whole is compared against Crossref’s repository of publication meta-data. The Formatted Citation Search handles basic citations very well but accuracy is not guaranteed. Results from Formatted Citation Search must be evaluated to ensure accuracy.

Crossref pays no transaction fees for the use of the FCS technology and therefore unlimited use is permissible.

Use Options {madcap:targetname=“Use Options”}

RefXpress usage: As much as is possible Crossref’s goal is to meet our user’s needs. The STQ tools backed by RefXpress meets the needs of nearly all individuals and many very small publishers. Crossref licenses RefXpress from Inera and pays a per transaction fee and therefore is not able to provide unlimited free access to Crossref STQ or API users.RefXpress is the default back-end used by Crossref’s Simple Text Query tools. Queries are limited to 1,000 per month for each registered email account.

In some cases additional free usage may be made available or arrangements may be made to provide metered service for a fee. RefXpress may also be enabled for use via the HTTP API for Crossref members but usage limits will have to be enforced. Contact support@crossref.org for details.

Please do not create/register multiple email accounts to circumvent this measure. Crossref monitors activity and may block querying for abusers or direct STQ activity to the FCS servicing technology.

Formatted Citation Search usage: Any Crossref user (members or registered email accounts) may ask to use the API or STQ interfaces with the FCS technology. Please contact support@crossref.org to have this permission enabled on your account.

Querying with special characters

Mon, 01 Jan 0001 00:00:00 +0000

Querying with special characters

The Crossref system does perform some fuzzy matching but for best results, when the deposited metadata for a DOI has special characters, queries for the DOI should also include special characters.

Example: DOI 10.1260/095830506778119452 was deposited with the metadata shown below. Notice that the first author surname (ámon) has a numerical character entity, in this case the character á.

+ show/hide example

…
<journal_article publication_type="full_text">
<titles>

<title>Twenty years after chernobyl in Hungary: the Hungarian perspective of energy policy and the role of nuclear power</title>
</titles>
<contributors>
<person_name sequence="first" contributor_role="author">
<given_name>Ada</given_name>
<surname> ámon </surname>
</person_name>
</contributors>
<publication_date ="print">
<month>7</month>
<day>1</day>
<year>2006</year>
</publication_date>
<publication_date ="online">
<month>7</month>
<day>29</day>
<year>2009</year>
</publication_date>
<pages>
<first_page>383</first_page>
<last_page>399</last_page>
</pages>
<publisher_item>
<identifier id_type="pii">C8612851662R7W4H</identifier>
</publisher_item>
<doi_data>
<doi>10.1260/095830506778119452</doi>
<timestamp>20100318031228</timestamp>
…

If we formulate a query that does not include page number we must include the author using the entity
and not some other form of character, for example:

No match:

<query key="mykey" enable-multiple-hits="false"> <journal_title>Energy & Environment</journal_title> <author>ámon</author> <volume>17</volume> <issue>3</issue> <year>2006</year> </query>

No match:

<query key="mykey" enable-multiple-hits="false"> <journal_title>Energy & Environment</journal_title> <author>amon</author> <volume>17</volume> <issue>3</issue> <year>2006</year> </query>

Match found:

<query key="mykey" enable-multiple-hits="false"> <journal_title>Energy & Environment</journal_title> <author>ámon</author> <volume>17</volume> <issue>3</issue> <year>2006</year> </query>

Relationships between DOIs and other objects

Mon, 01 Jan 0001 00:00:00 +0000

Relationships overview

On line publications and physical print publications with a digital fingerprint often do not exist as a single content item. Many parts comprise electronic publications which are often produced, curated, and published by different organizations and separate activities. A complete representation of a particular work requires interlinking this assemblage of parts in a navigable infrastructure that allows both readers and machines to consume the entirety of a specific intelectual property given the distributed locations of its parts.

Reference linking was the first service established by Crossref to address this need at the dawn of on-line scholarly publishing. Connecting the articles, and other content, identified in the bibliography, using the actionable DOI created a navigable citation network. Since then, Crossref has introduced other interlinking services that address specific types of relationships. Crossmark supports the connection of ‘updates’ which have a material effect on the original work, for example in the most extreme a retraction. Funding data supports identifying the organization that financially supports the research behind a specific publication. Components allow for the assignment of DOIs to the elemental parts of a publication (figures, tables, images) which may lead to their reuse. These and other Crossref services create relationships between content items; however, they share two characteristics that restrict their ability to define relationships.

Both items involved in a relationship must be identified by Crossref assigned DOIs.
The types of relationships are dictated by the mission of the specific Crossref service.

Modified and new services developed in response to these two limitations.

Allow non Crossref DOIs to be deposited in an item’s (article/chapter/paper) list of citations.
Support the creation of general typed relations between items having a Crossref DOI and other content items represented by a variety of identifiers.

Declaring relationship types

The nature of possible relationship types between content items can be as varied as the nature of the items themselves. Constructing an orderly mapped network of content requires the use of a controlled vocabulary that defines these relationships. Crossref’s services achieve this in both 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 in an explicit approach where the relation type is selected as a value within the deposited metadata.

Linking and CitedBy: Implicitly creates ‘cites’ and ‘isCitedBy’ relations between a content item and the items in its bibliography.
Crossmark: Explicit creation of update relations between an item and other items that material effect it (ex. a retraction).
Funding data: Implicit creation of ‘isFundedBy’ and ‘hasAward’ relations 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).
Gernal typed relations: Explicitly typed relation between an item having a Crossref DOI and an item having one of several possible identifiers.

General typed relations

This service allows for the creation of a typed relationship between an item having 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 (+ show/hide ). 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 when a relation is created in the deposit of one item in a pair. The DOI deposited 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

A single journal article is published in two languages with each being assigned its own DOI. In this factious example both are published in the same journal. The original language instance has metadata that contains no indication of the translation instance (+ show/hide ). The alternate language instance includes in its metadata a relation to the original language instance (+ show/hide )

Original language article deposit

Translated article deposit

Example

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 10.1007/978-3-642-56843-5.

The current metadata for the review article gives no indication of the actual book being reviewed (+ show/hide).

Modifications to the review’s metadata show how it would include a relationship to the book (+ show/hide).

Meanwhile, the book’s deposited metadata shows no indication of the relation to the review article (+ show/hide).

Relations API show the relationship from the point of view of both DOIs (+ show/hide).

http://doi.crossref.org/relations/find?doi=10.1007/978-3-642-56843-5

http://doi.crossref.org/relations/find?doi=10.1191/0959683602hl565xx

Book DOI’s metadata showing the relationship (+ show/hide).

Example

An article having 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.

The article’s Crossref deposited XML (+ show/hide)

The relationship API view of the DataCite DOI (+ show/hide)

Why do this?

Creating relationships helps build a mapping of scholarly objects as desribed in Jennifer Lin’s posting “Crossref & the Art of Cartography”. Expressing these relationships in metadata now will enable the evolving infrastructure to leverage this mapping.

Reports Overview

Mon, 01 Jan 0001 00:00:00 +0000

Crossref reports

Crossref provides a number of reports which can be used to maintain and assess deposited DOIs and metadata.

Members area reports

All web site reports are available in the Crossref members area.

Depositor report:lists all DOIs by title for journals, books, and conference proceedings
Missing Metadata (Field) report:contains details regarding completeness of metadata
Crawler report: lists results of DOI resolution testing
Conflict report: lists conflicts by publisher and title, email alert sent out monthly (when needed)
Quarterly deposit report: quarterly list of number of back year, current year, and updated DOIs, by publisher and title
Title list: browsable list of journal, book, and conference proceedings titles deposited with Crossref
XML journal list (mddb.xml): XML list of journal titles deposited with Crossref
Status report:deposit and query volume
Go-live report:lists all Crossref members, DOI prefixes, and date of last activity

Emailed reports

Some publisher-specific reports are sent out by email.

Resolution report: monthly statistics about member DOI resolutions
DOI Error Report: aggregated notification of DOI errors reported by end users, sent out nightly (when needed)
Schematron Report:post-deposit metadata quality report, sent out weekly as needed

Resolution by country code

Mon, 01 Jan 0001 00:00:00 +0000

DOI resolution by country code

Crossref’s implementation of multiple resolution supports a form of appropriate copy based on the country of origin of the user requesting the resolution service. This service allows a content owner to deposit multiple URLs for a single DOI, each of which is intended to service users from a particular country. The DOI resolver will determine the resolution request’s country of origin and select the appropriate URL target based on country codes (available here).

The country code and URL information are supplied within the <collection> element, and can be deposited as part of a primary metadata deposit or as a resource deposit. If a country code is not supplied, the DOI will resolve to the URL supplied in the top level resource element .

Metadata deposit:

<doi_data>
<doi>10.5555/ilovedois</doi>
<resource>http://www.crossref.org/hello default URL
  <collection property=“country-based”>
<item country=“US”>
<resource>http://www.crossref.org/howdy USA URL
</item>
   <item country=“SE”>
<resource>http://www.crossref.org/hej Sweden URL
</item>
   <item country=“KE”>
<resource>http://www.crossref.org/hujambo Kenya URL
</item>
</collection>
</doi_data>

Resource-only deposit:

<doi_resources>
<doi>10.5555/ilovedois</doi>
<collection property=“country-based”>
<item country=“US”>
<resource>http://www.crossref.org/howdy USA URL
</item>
<item country=“SE”>
<resource>http://www.crossref.org/hej Sweden URL
</item>
<item country=“KE”>
<resource>http://www.crossref.org/hujambo Kenya URL
</item>
</collection>
</doi_resources>

Resolution report

Mon, 01 Jan 0001 00:00:00 +0000

Resolution Report

Resolution reports are sent out via email at the beginning of each month and includes statistics about DOI resolutions from the previous month. A separate report is generated for each DOI prefix. The statistics are based on the number of DOI resolutions through the DOI proxy server (http://dx.doi.org/) on a month-by-month basis and include:

resolution failure rate: the percentage of DOI resolution attempts that failed. The prefix failure rate and the overall failure rate (for all Crossref members) are included.
resolutions by month:total number of resolutions per month for the past 12 months, by prefix (Count) and overall (All Members). + show/hide example
resolution stats:resolution counts for the report prefix. + show/hide example

Resolution attempts is the number of requests for DOIs owned by the specified prefix.

Resolved at handle is the number of resolutions that successfully looked up at dx.doi.org.

Handle failures is the number of resolutions that failed to look up at dx.doi.org, either due to a technical problem or because the DOIs did not exist.

Resolved at local link server number of resolutions that were looked up at local link servers.

Unique DOIs attempted is the number of unique DOIs represented in the total Resolutions attempts.

Unique DOIs resolved at handle is the number of unique DOIs represented in the Resolved at Handle count.

Unique DOIs that failed at handle is the number of unique DOIs represented in the Handle Failures count.

Unique DOIs resolved at local link server is the number of unique DOIs represented in the Resolved at local link server count.
Top ten DOIs:list of the ten DOIs with the highest number of successful resolutions for the month, and the number of times each DOI was successfully resolved. + show/hide example
Failed DOIs:a list of DOI resolution attempts that failed (i.e. resolved to a Handle error page). This list is presented as a .csv file attached to the report email and contains both the failed DOI and number of failures. + show/hide example

These statistics give an indication of the traffic generated by users clicking DOIs. The DOI links are largely from links in other publishers’ journal references to articles, but they are also from DOI links in secondary databases, links from libraries using DOIs, and even DOIs in used in print versions.

When a researcher clicks on a DOI link for an article, that counts as one DOI resolution. For example, clicking on http://dx.doi.org/10.1038/nature02426 counts as one resolution to Nature. No information is captured about who the user is or where they are coming from. The information on DOI resolutions is captured by the web server logs on http://dx.doi.org/ which is run by CNRI on behalf of the International DOI Foundation. These numbers are not a precise measure of traffic to a publisher’s website - cached articles, search engine crawlers not following re-direction, and traffic that is directed to a locally appropriate copy through a library link resolver would be included in these numbers, but would not result in inbound traffic to a website. Nevertheless, these numbers provide an important measure of the effectiveness of a member’s participation in Crossref.

We filter out known search engine crawlers. The overall number of filtered crawler resolutions for the month is included in the report.
Resolution reports are sent to the business contact on file. To redirect the report or add additional contacts, contact support@crossref.org.
See Working with your Resolution Report for additional details

Resolving conflicts

Mon, 01 Jan 0001 00:00:00 +0000

Resolving conflicts

You can resolve such conflicts in one of three ways:

Update the metadata for one or more DOIs so each is unique
Make one DOI primary and the other DOI an alias
Accept a conflict as-is by changing its status to “resolved”without making any changes

Crossref has instituted a penalty fee which may be imposed when staff is required to resolve a conflict

To resolve conflicts:

Identify the conflicts and view details about them by examining your deposit log, examining the Conflict report or using the web interface.
Resolve conflicts by:
- uploading a special control file to the system (best option for resolving multiple conflicts).
- Assigning primary and alias status to DOIs using the system’s user interface.
- Updating the metadata for one or more of the DOIs involved in the conflict so that it can be distinguished from each other. Then re-deposit this new metadata will Crossref.
- Accepting the conflicts as-is.

If you need to resolve a large number (hundreds or more) of conflicts, contact Crossref for assistance.
If a conflict involves another publisher’s DOI(s), contact Crossref for assistance.
Publishers can force a DOI to be an alias of another even if those 2 DOIs are not in conflict.
For specific scenarios that cause conflicts, see sample conflict scenarios.

Resource-only deposits

Mon, 01 Jan 0001 00:00:00 +0000

DOI resource deposits

Some metadata updates or additions may be deposited separately from metadata deposits as resource deposits. These deposits append the included metadata to the citation metadata already stored in the Crossref system, and do not need to be included in citation metadata updates. Resource deposits use the resource-only schema (with the exception of stand-alone components which use the main deposit schema).

Uploading resource deposits

Resource deposits may only be submitted for existing Crossref DOIs. Deposits using the resource-only schema must be uploaded with type ‘doDOICitUpload’ for HTTP POST (or ‘DOI Resources’ when using the system interface).

Supported resource-only deposit types:

Reference deposits
URLs: A primary URL must be included in all DOI deposits. Additional URLs may also be included, for:
- as-crawled URLs (used for CrossCheck)
- Multiple Resolution secondary URLs
- content version ortext and data mining URLs
Components
Funding metadata (funding)
Crossmark: implementation guidelines | sample Crossmark-only deposit
Access Indicators (text and data mining)

Retrieving DOI history

Mon, 01 Jan 0001 00:00:00 +0000

Viewing the history of a DOI

The deposit history of individual DOIs may be retrieved using the Crossref system interface. A DOI’s history includes all deposit files and submission logs.

Accessing DOI history

To view a DOI history report:

Access the Crossref system.
Click the Report tab.
Click the Misc. Reports tab.
Enter or paste a DOI in the box.
Click Show to view the report online.

The report lists every successful deposit or update of the DOI being searched. The submission details (including log and submitted XML) can be viewed by clicking on the submission number:

Retrieving DOI info-metadata

Mon, 01 Jan 0001 00:00:00 +0000

Retrieving DOI info-metadata

Crossref system-specific information about a DOI may be retrieved by including the appropriate parameters in the following URL:

https://doi.crossref.org/search/doi?pid=<USERNAME:PASSWORD>&format=info&doi=<DOI>

This data is distinct from item metadata deposited for each DOI, and includes information such as timestamp, owner prefix, and primary/alias status.

Sample info-metadata:

DOI: 10.2353/jmoldx.2009.090037 CITATION-ID: 39306481 JOURNAL-TITLE: The Journal of Molecular Diagnostics JOURNAL-CITE-ID: 58207 BOOK-CITE-ID: SERIES-ID: DEPOSIT-TIMESTAMP: 20110701073812000 OWNER: 10.1016 LAST-UPDATE: 2011-07-04 21:13:59 PRIME-DOI: none

A list of DOIs for a title may be retrieved using format=doilist, details are available here.

Retrieving DOIs by title

Mon, 01 Jan 0001 00:00:00 +0000

Retrieving DOIs by title

A list of DOIs by title may be retrieved using the following format:

https://doi.crossref.org/search/doi?pid=&format=doilist&pubid=<content type><PUBID>

where:

pid = Crossref system login orquery services email address
content type = J for journals, B for books or confererence proceedings, S for series
pubid = publication ID

for example:

https://doi.crossref.org/search/doi?pid=your@email.com&format=doilist&pubid=J173705

The results returned match the title detail results from the depositor report, and include a list of all DOIs for the title, the owner prefix for each DOI, the timestamp used in the most recent deposit, and the data the DOI was last updated.

Retrieving cited-by links

Mon, 01 Jan 0001 00:00:00 +0000

Retrieving Cited-by Links

Publishers participating in Cited-by Linking are able to retrieve a list of items that cite a specific target article. Only the owner of the target article will be able to retrieve cited-by matches. New cited-by links to a target item can be established at any time when some other publisher deposits an article citing the target item. To ensure cited-by links are up to date, publishers should either query regularly for cited-by links or (if performing XML queries) set the alert attribute to “true”.

XML Queries

The primary method of retrieving cited-by links is to submit a cited-by linking query using the Crossref query schema. The query contains only the DOI of the cited article stored in the fl_query element.

Setting the alert attribute to “true” instructs the Crossref system to remember this query and to send new cited-by link results to the specified email address when they occur.

+ show/hide example

Query:

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/qschema/2.0 http://www.crossref.org/qschema/crossref_query_input2.0.xsd"> <head> <email_address>your@email.com</email_address> <doi_batch_id>fl_001</doi_batch_id> </head> <body> <fl_query alert="true"> <doi>10.1053/sonc.2002.35642</doi> </fl_query> </body> </query_batch>

Result:

<?xml version="1.0" encoding="UTF-8"?> <crossref_result version="2.0" xmlns="http://www.crossref.org/qrschema/2.0"0.xsd"> <query_result> <head> <email_address>support@crossref.org</email_address> <doi_batch_id>fl_001</doi_batch_id> </head> <body> <forward_link doi="10.1053/sonc.2002.35642"> <journal_cite> <issn type="electronic">15321827</issn> <issn type="print">00070920</issn> <journal_title>British Journal of Cancer</journal_title> <article_title>Introduction</article_title> <contributors> <contributor first-author="true"> <given_name>U</given_name> <surname>Gatzemeier</surname> </contributor> </contributors> <volume>89</volume> <first_page>S1</first_page> <year>2003</year> <publication_type>full_text</publication_type> <doi type="journal_article">10.1038/sj.bjc.6601475</doi> </journal_cite> </forward_link> <forward_link doi="10.1053/sonc.2002.35642"> <journal_cite> <issn type="print">10870156</issn> <journal_title>Nature Biotechnology</journal_title> <article_title>Monoclonal antibody therapy of cancer</article_title> <contributors> <contributor first-author="true"> <given_name>Gregory P</given_name> <surname>Adams</surname> </contributor> <contributor first-author="false"> <given_name>Louis M</given_name> <surname>Weiner</surname> </contributor> </contributors> <volume>23</volume> <issue>9</issue> <first_page>1147</first_page> <year>2005</year> <publication_type>full_text</publication_type> <doi type="journal_article">10.1038/nbt1137</doi> </journal_cite> </forward_link> <forward_link doi="10.1053/sonc.2002.35642"> <journal_cite> <issn type="print">08853177</issn> ....

Cited-by linking XML queries can be submitted just like any other query. For details, review How querying works.

Alerts are not emailed immediately when a cited-by match is made, there is sometimes a delay of several weeks.

HTTP queries

An alternative to using the XML query format described above will be to send in simpler HTTP requests as shown below. Alerts cannot be enabled via HTTP querying. The response to HTTP requests will also be formatted as XML.

DOI query (results by DOI or prefix): This format retrieves all cited-by matches for a single DOI (or prefix) within a specified date range:

https://doi.crossref.org/servlet/getForwardLinks?usr=&pwd=<password>&doi=<doi>&startDate=<startDate>&endDate=<endDate>

You may also retrieve cited-by matches established on a single day for a single DOI or prefix:

https://doi.crossref.org/servlet/getForwardLinks?usr=&pwd=<password>&doi=<prefix>&date=YYYY-MM-DD

Date range (*startDate* and endDate, or YYYY-MM-DD) and *doi* parameters are required. Results for an entire prefix may be retrieved by supplying the prefix as the <doi> value.

Depending on the volume of matches this query might time out, a short date range is recommended.

OAI-PMH request (results by prefix or title):This format retrieves cited-by matches established within a date range for a prefix or for a given title. Supply a prefix only (no pubID) to retrieve all results for a prefix. Only the prefix owner may retrieve matches. Date range is required.

https://oai.crossref.org/OAIHandler?verb=ListRecords&usr=&pwd=<password>&set=J:<prefix>:<pubID>&from=YYYY-MM-DD&until=YYYY-MM-DD&metadataPrefix=cr_citedby

where:

username and password: system login for the prefix/title being retrieved

content type: J for journal, B for books, conference proceedings, datasets, reports, standards, or dissertations, and S for series

*prefix*: the owning prefix of the title being retrieved

*pubID*: thepublication identification number assigned by the Crossref system.

OAI-PMH requests only return a list of citing DOIs. Metadata is currently not included. + show/hide example

<OAI-PMH xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <responseDate>2011-12-13T09:51:59</responseDate> <request verb="ListRecords" set="J:10.1007:3234">http://oai.crossref.org/OAIHandler</request>  <ListRecords> <record> <header> <identifier>info:doi/10.1007/BF00705816</identifier> <datestamp>2009-04-21</datestamp> <setSpec>J:10.1007:3234</setSpec>  </header> <metadata> <citations> <citation xmlns="http://www.crossref.org/schema/crossref_citations_1.0.0"> <doi>10.1007/BF00705816</doi> <citations-cited-by> <doi>10.1007/BF01133383</doi> <doi>10.1016/S0167-577X(97)00196-1</doi> <doi>10.1016/j.desal.2006.03.578</doi> <doi>10.1007/s11771-008-0060-5</doi> <doi>10.1016/S0025-5408(99)00105-1</doi> <doi>10.1016/j.micromeso.2005.05.016</doi> <doi>10.1016/S0924-2031(99)00058-2</doi> <doi>10.1002/jrs.1250260840</doi> <doi>10.1007/BF02903455</doi> </citations-cited-by> </citation> </citations> </metadata> </record> ...

Some OAI-PMH requests are too big to be retrieved in a single transaction. If a given response contains a resumption token the user must make an additional request to retrieve the rest of the data.See OAI-PMH query interface for details.

Reversing multiple resolution

Mon, 01 Jan 0001 00:00:00 +0000

Reversing multiple resolution

Multiple Resolution can be reversed if the service is no longer needed for a DOI. This can be done by either:

Deleting deposited interim page data:secondary URLs can from a DOI by submitting a secondary deposit with an empty <item> element within a collection, or with an empty <collection> element. This will remove any URLs submitted by the secondary depositor from both the interim page and query response XML.
+ show/hide example

<?xml version="1.0" encoding="UTF-8"?> <doi_batch version="4.3.0" xmlns="http://www.crossref.org/doi_resources_schema/4.3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/doi_resources_schema/4.3.0 http://www.crossref.org/schemas/doi_resources4.3.0.xsd"> <head> <doi_batch_id>123456</doi_batch_id> <depositor> <name>xyz</name> <email_address>pfeeney@crossref.org</email_address> </depositor> </head> <body> <doi_resources> <doi>10.50505/mrtest1</doi> <collection property="list-based"> <item /> </collection> </doi_resources> </body> </doi_batch>

Deposits made by primary and other secondary depositors will not be affected, and the DOI may still be updated with new Multiple Resolution URLs. The deposit account used to submit the update file must be the same account used to create the secondary URLs.
Locking a Multiple Resolution DOI: the content owner of a DOI may “lock” the DOI, preventing any future Multiple Resolution deposits. The empty <item> element described above should be submitted as well if the content owner wishes to remove already-deposited Multiple Resolution URLs.
+ show/hide example

<?xml version="1.0" encoding="UTF-8"?> <doi_batch version="4.3.0" xmlns="http://www.crossref.org/doi_resources_schema/4.3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/doi_resources_schema/4.3.0 http://www.crossref.org/schemas/doi_resources4.3.0.xsd"> <head> <doi_batch_id>123456</doi_batch_id> <depositor> <name>xyz</name> <email_address>pfeeney@crossref.org</email_address> </depositor> </head> <body> <doi_resources> <doi>10.50505/mrtest1</doi> <collection multi-resolution="lock" property="list-based">

<item /> </collection> </doi_resources> </body> </doi_batch>

Submitting an empty collection tag (as is done when unlocking DOIs) will remove any deposited secondary URLs.

Role of the DOI proxy

Mon, 01 Jan 0001 00:00:00 +0000

Role of the DOI proxy

Significant changes were made to the DOI proxy (dx.doi.org), which is maintained by CNRI on behalf of the IDF, in order to implement multiple resolution. Prior to these changes the resolution service provided by the proxy were a very simple redirection to single URL (known by many as the default URL). In this mode each DOI had one URL which would always be selected whenever a user requested resolution. The Handle system stores DOI data in properties or name value pairs and the name for this property was URL.

Multiple resolution required the introduction of an additional Handle property for DOIs to exhibit this new behaviour. This property is called “10320/loc”, which is itself a Handle.

Sample Handle record:

In the sample handle record the default URL is set to represent the content’s primary location. This is typically the platform of the content owner, or its primary publisher. The presence of property 10320/loc, containing an XML snippet, indicates to the proxy that multiple resolution is enabled for this DOI. The XML is interpreted as follows:

<locations> element, chooseby: specifies the order of rules to be applied by the proxy when selecting from the<location> elements.
- locatt: used if the DOI request specifies a specific location item
- country: used if any location item specifies a specific country which must match the country of the requester
- weight: a weighted random selection from those <location> elements having weight values
<location> element identifies a specific location
- id: a unique ID given to each location element
- cr_type: a Crossref property that specifies the type of multiple resolution to support
- cr_src: a Crossref property that identifies which Crossref user deposited the location value
- label: used by Crossref to identify the co-host
- href: the URL of the location
- weight: the weighted value to use when applying the weighted-random selection process

The presence/absence of a rule in the chooseby property will enable/disable that type of selection process by the proxy.

For Crossref’s interim page multiple resolution we are setting the weight of the interim page location to 1 and all other locations to zero. This will cause the weighted-random rule to always select the interim page location. Crossref’s interim page application will then display to the use the set of choices which will consist of the default URL along with all other <location>s.

DOI resolution requests may be structured to bypass the Crossref interim page using features built into the proxy’s multiple resolution capabilities.

To force the DOI to resolve to the primary (original) host location:

http://dx.doi.org/10.50505/200806091300**?locatt=mode:legacy**

To force the DOI to resolve to a specific location:

http://dx.doi.org/10.50505/200806091300**?locatt=label:HOST-XYZ**

Sample conflict resolution files

Mon, 01 Jan 0001 00:00:00 +0000

Sample conflict resolution files

Conflict resolution files must have a ‘.txt’ extension. They should be created with a text editor. Files may be uploaded using the system interface.

Make primary:DOIs in this file will be marked ‘primary’ in any conflicts:

H:email=youremail@address.com;op=primary
10.1016/0032-1028(80)90001-2
10.1016/0032-1028(80)90002-4
10.1016/0032-1028(80)90003-6
10.1016/0032-1028(80)90004-8
10.1016/0032-1028(80)90005-X
10.1016/0032-1028(80)90006-1
10.1016/0368-3281(63)90014-7

Alias: DOIs in this file will be marked ‘alias’ in any conflicts:

H:email=youremail@address.com;op=alias
10.1016/0032-1028(80)90001-2
10.1016/0032-1028(80)90002-4
10.1016/0032-1028(80)90003-6
10.1016/0032-1028(80)90004-8
10.1016/0032-1028(80)90005-X
10.1016/0032-1028(80)90006-1
10.1016/0368-3281(63)90014-7

Use op=ALIAS when the primary DOIs are not known. If there are more than two DOIs involved in the conflict, the operation is rejected because the system cannot determine which DOI to make primary.

Force alias: DOIs in the second column will be aliased to DOIs in the first column, regardless of conflict status:

H:email=youremail@address.com;op=force_alias;delim=tab
10.5555/a.b.c.c 10.5555/a_b.c.c
10.5555/a.b.c.d 10.5555/a_b.c.d

10.5555/a.b.c.e 10.5555/a_b.c.e

Sample conflict scenarios

Mon, 01 Jan 0001 00:00:00 +0000

Sample Conflict Scenarios

The following scenarios describe situations in which conflicts do or do not arise and why:

Scenario 1: No conflict due to distinguishing type element + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1 with type Full_Text
MD_1 as DOI_2 with type Abstract_Only
MD_1 as DOI_3 with type of Bibliographic_Record

In this case, even though the metadata is identical for all three records, type distinguishes the records from one another and no conflicts occur.

Scenario 2:Conflict resolved by assigning primary status + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1
MD_1 as DOI_2

The Crossref system accepts DOI_2 but flags a conflict with DOI_1.

A metadata query for MD_1 without the multi-hit option selected would return no results.

The publisher resolves the conflict assigning primary status to DOI_1 and alias status to DOI_2.

A metadata query on MD_1 now returns DOI_1, and a DOI query on either DOI_1 or DOI_2 will return MD_1.

Scenario 3: Conflict resolved by updating data (version 1) + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1
MD_1 as DOI_2

The Crossref system flags a conflict between DOI_1 and DOI_2.

The publisher submits this update for DOI_1, which resolves the conflict:

MD_2 as DOI_1

Scenario 4: Pre-publication conflict resolved when page numbers updated + show/hide example

Before hard-copy publication, a publisher submits metadata in the following sequence:

MD_1 as DOI_1 with no page number
MD_2 as DOI_2 where MD_2 also has no page number, making it identical to MD_1

The Crossref system flags a conflict because without the page numbers, it cannot differentiate between MD_1 and MD_2.

After publication, the publisher submits the following, which automatically resolves the conflict:

MD_1 as DOI_1 with page number
MD_2 as DOI_2 with page number

Scenario 5: Multi-way conflict created + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1
MD_1 as DOI_2

The Crossref system flags a conflict between DOI_1 and DOI_2. The publisher then submits:

MD_1 as DOI_3

The Crossref system flags a second conflict between DOI_1, DOI_2, and DOI_3.

Scenario 6: One conflict resolved but another created (version 1) + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1
MD_1 as DOI_2

The Crossref system flags a conflict between DOI_1 and DOI_2.

The publisher manually resolves the conflict by assigning primary status to DOI_1. The publisher then submits:

MD_1 as DOI_3

The Crossref system flags a second conflict between DOI_1 and DOI_3 only. DOI_2 is not involved in the conflict because it is an alias of DOI_1.

Scenario 7: One conflict resolved but another created (version 2) + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1
MD_1 as DOI_2
MD_2 as DOI_3

The Crossref system flags a conflict between DOI_1 and DOI_2. The publisher then submits:

MD_2 as DOI_2

The Crossref system automatically resolves the first conflict, but it flags a second conflict between DOI_2 and DOI_3.

Scenario 8: Conflict partially resolved + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1
MD_1 as DOI_2

The Crossref system flags a conflict between DOI_1 and DOI_2. The publisher then submits:

MD_1 as DOI_3

The Crossref system flags a second conflict between DOI_1, DOI_2, and DOI_3. The publisher then submits:

MD_2 as DOI_3

The Crossref system automatically resolves the first conflict and removes DOI_1 from the second conflict, but DOI_2 and DOI_3 are still involved in the second conflict.

Scenario 9: Conflict resolved by updating data (version 2) + show/hide example

A publisher submits metadata in the following sequence:

MD_1 as DOI_1

MD_1 as DOI_2

The Crossref system flags a conflict between DOI_1 and DOI_2. The publisher then submits:

MD_1 as DOI_3

The Crossref system flags a second conflict between DOI_1, DOI_2, and DOI_3. The publisher then submits:

MD_2 as DOI_3

The Crossref system automatically resolves the second conflict because DOI_3 is not longer causing it.

Schematron report

Mon, 01 Jan 0001 00:00:00 +0000

Schematron report

Crossref performs a post-deposited metadata quality check on all journal, book, and conference proceedings submissions. Any identified errors may affect overall metadata quality and negatively affect queries for your content. Errors are aggregated and sent out weekly via email as the ‘Schematron report’. The report contains links (organized by title) to .xml files containing error details. The XML files can be downloaded and processed programmatically, or viewed in a web browser: + show/hide example

Schematron is a pattern-based XML validation language, more information is available at http://www.schematron.com/.
Schematron validation is available for individual file uploads, or Crossref’s Schematron rules may be downloaded for batch processing.

Secondary query

Mon, 01 Jan 0001 00:00:00 +0000

Secondary queries

The Crossref query engine operates by processing many different rules. By default, all metadata provided in a query is used to generate a match, and a match is only returned if one DOI is present. Enabling a secondary query instructs the query engine to perform specific searches when the initial search fails to find a match.

Author/title secondary query

Queries by default use all metadata present in the request. Requests with only an author and title are treated as author/ article title queries. When other fields are present, the request is submitted as a metadata search.

Setting the secondary-query attribute to “author-title” causes an author/title search to be performed when the initial metadata search fails to produce a result.

<query key="cit-3" enable-multiple-hits="true" secondary-query="author-title"> <issn>0360-3016</issn> <volume>54</volume> <issue>2</issue> <first_page>215</first_page> <year>2002</year> <author>Kim</author> <article_title match="fuzzy">Potential radiation sensitizing effect of SU5416 by down-regulating the COX-2 expression in human lung cancer cells</article_title> </query>

Year is included in the author / article title secondary query when present. An author/ article title query will only be performed if both author and article title are included in the query.

Multiple hits secondary query

By default, the query engine will only return a result if a single DOI is found. Queries returning multiple results (or hits) are unresolved. Setting the secondary-query attribute to “multi-hit” instructs the query engine to return all available results.

<query key=“cit-3” secondary-query=“multiple-hits”>
<issn>0360-3016</issn>
<volume>54</volume>
<issue>2</issue>
<first_page>215</first_page>
<year>2002</year>
<author>Kim</author>
<article_title match=“fuzzy”>Potential radiation sensitizing effect of SU5416 by down-regulating the COX-2 expression in human lung cancer cells</article_title>
</query>

This option can also be performed bysetting attribute enable-multiple-hits to “true”

Author/title multiple hits secondary query

Setting the secondary-query attribute to “author-title-multiple-hits” instructs the query engine to perform an author/title query and return multiple hits if the initial search fails.

<query key=“cit-3” enable-multiple-hits=“true” secondary-query=“author-title-multiple-hits”>
<issn>0360-3016</issn>
<volume>54</volume>
<issue>2</issue>
<first_page>215</first_page>
<year>2002</year>
<author>Kim</author>
<article_title match=“fuzzy”>Potential radiation sensitizing effect of SU5416 by down-regulating the COX-2 expression in human lung cancer cells</article_title>
</query>

Secondary query results

Query results will specify which method was used to return the result. Successful metadata searches will specify “metadata”:

Queries resolved by the secondary author/title query will specify “author-title”:

Queries with multiple hits will have a status of “multiresolved”>

Setting up your system for localized linking

Mon, 01 Jan 0001 00:00:00 +0000

Setting up your system for localized linking {style=“text-align: left; margin-bottom: 2pt; font-family: Verdana; line-height: normal; “}

To take advantage of localized linking, your localized linking server must have a recognized BASE-URL. BASE-URLs are collected from library affiliates when they sign up with Crossref, and forwarded to the IDF for registration.

Once the BASE-URL is registered, go to *http://www.doi.org/cgi-bin/pushcookie.cgi?BASE-URL={your BASE-URL}* to download a cookie, which contains the URL for your local content server. This cookie makes your browser OpenURL-enabled, which means that the Crossref system will redirect relevant requests to your local resolver.

If you upgrade or change your local link resolver, send your new BASE-URL to support@crossref.org.

For more detailed information about BASE-URL and cookie pusher script, see http://www.exlibris-usa.com/category/sfxcookiepusher.

ShortDOI

Mon, 01 Jan 0001 00:00:00 +0000

ShortDOI

The ShortDOI service is an open system that creates shortcuts to DOI names. The service creates short handles and enables permanent links that are very short. This can be important in situations where space is limited.

For example for the DOI http://dx.doi.org/10.1016/S1097-2765(03)00225-9 the short form is http://doi.org/bm6

A benefit of the ShortDOI service is that only one ShortDOI is created for each DOI Name and the ShortDOI returns exactly the same results as the DOI name. For more information go to http://shortdoi.org/

Simple Text query form

Mon, 01 Jan 0001 00:00:00 +0000

Simple Text Query

The Simple Text Query allows users to retrieve DOI names for journal articles, books, and chapters by simply cutting and pasting a reference or reference list into the query box. References are input as a standard bibliographic entry, such as:

Example:

Clow GD, McKay CP, Simmons Jr. GM, and Wharton RA, Jr. 1988. Climatological observations and predicted sublimation rates at Lake Hoare, Antarctica. Journal of Climate 1:715-728.

For best results, each reference should appear on a single line. When submitting multiple references, enter them in alphabetical order or as a numbered list. Separate individual references using a blank line.

Interactive simple-text query form

Access the Simple Text Query form
*Note: Simple Text Query users must register for access using a verifiable email address.*
Enter a reference using the preceding example as a guide.
Press Enter and enter another reference if needed. Repeat this step as necessary.
Select theList All Possible DOIs per Reference option to find all possible matches.

Note: Crossref attempts to find exactly one DOI for each reference. However, if the metadata extracted from your reference or the metadata in Crossref do not allow this level of precision, selecting List All Possible DOIs lets you examine the candidate list and choose the correct DOI yourself.

Click Submit.

This service is currently being offered free of charge to the public and has a capacity limitation of a couple dozen references per submittal. The Simple Text Query is not an appropriate tool for high volume operations and queries are limited to 1,000 per month. This limit is intended to be a limit on an individual, or the organization represented by an individual. Please contact Crossref (member@crossref.org) to inquire about options appropriate for volumes of use above these limits.

For publishers participating in cited-by linking, the SimpleText Query form may also be used to deposit references.

Simple Text reference deposit

Mon, 01 Jan 0001 00:00:00 +0000

Using the Simple Text Query form to deposit references

Crossref’s cited-by linking service allows publishers to deposit the references for an article along with its DOI. This form allows you to deposit references in a cut-and-paste interface.

To deposit references:

Enter your references into the Simple Text Query form and select Submit.

be sure the tick box for ‘List all possible DOIs per reference’ is not selected.
Select the Deposit button and complete the fields that appear:

email: your email address (a submission log will be emailed to you after your reference deposit has been processed)
Parent DOI: the DOI of the article (or chapter, report, etc.) for which you are submitting references
username / password:your Crossref system account login
Again select Deposit.

If your details have been entered correctly you will see a “Success’ message. This indicates that your deposit has been submitted to the system queue. When the reference deposit has been processed you will receive submission log via email. You will also receive an email containing the XML deposit generated by the form.

This deposit is processed as a complete set, which means that any previous deposit of citations for this article will be replaced in full by any subsequent deposits. You may deposit an incomplete set – just remember to include previous references each time you make a deposit.
The reference deposit will include all references that were parsed by the XStyles engine and not just those that returned a DOI. Crossref will ‘remember’ any non-DOI matched references and will attempt to find a match in the future.
The Simple Text Query form is not an appropriate tool for high volume operations and monthly usage limits of 1000 references are in place.

Standards

Mon, 01 Jan 0001 00:00:00 +0000

Standards

Standard is the top level element for deposit of metadata about standards developed by Standards Development Organizations (SDOs) or Consortia. The metadata for standards differ from other content types primarily in the inclusion of additional designators along with the title which are commonly used when referring to a standard. Crossref added a <standard_designator> element with schema version 4.3.3.

As of schema version 4.3.3, Crossref requires that the full standard designation be placed in the <as_published> element (within <standard_designator>). In addition, Crossref requires that the publisher of the standard be included in <standards_body_name>, and the acronym within <standards_acronym>. The <as_published> and <standards_acronym> elements will be combined to identify a standard for query matching.

Standards are assigned a DOI at the title level and may also have DOIs assigned to lower level “content-items”. Standards published as stand alone publications do not need an ISBN, if an ISBN exists for a standard it should be included in deposits. If standards are published in a series an ISSN is required.

All standard deposits must use schema version 4.3.3 and up.
Sample standard deposit file

Status report

Mon, 01 Jan 0001 00:00:00 +0000

Viewing a Status report

The Status report displays information about monthly activity in the Crossref system. At the top of the report, summary statistics are provided for:

Total number of records in the Crossref system
Total number of DOIs registered
Total number of journals, books, and conference proceedings stored in the database
Total number of journal, book, and conference DOIs registered in the system.

In addition, the Status report displays the following information for deposits:

Month – Year or month in the current year for which data is provided.
Total Records Added – Total number of records added to the MDDB.XML database during that year or month.
Total Current Deposits – Total number of deposits submitted to the database during that year or month for content item’s published during that previous year or the current year.
Total BackFile Deposits – Total number of deposits submitted to the database during that year or month for content item’s published during a previous year.
Total Records Updated – Total number of records updated in the database during that year or month.

The Status report also displays the following information for queries:

Month – Year or month in the current year for which data is provided.
Total Metadata Queries – Total number of metadata queries submitted to the Crossref system during that year or month.
Total Matches – Total number of metadata queries resolved by the Crossref system during that year or month.
% – Percentage of metadata queries resolved compared with the total number of metadata queries submitted during that year or month.
% by Group (Lib, Pub, Aflt) – Percentage of queries submitted by each type of Crossref user compared with the total number of metadata queries submitted during that year or month.
Total DOI Queries – Total number of DOI queries submitted to the Crossref system during that year or month.
Total Matches – Total number of DOI queries resolved by the Crossref system during that year or month.
% – Percentage of DOI queries resolved compared with the total number of metadata queries submitted during that year or month.

Steps for implementation

Mon, 01 Jan 0001 00:00:00 +0000

Implementing Multiple Resolution

Multiple resolution typically involves coordination between a primary depositor and a secondary depositor, the primary depositor being the content owner, and the secondary depositor(s) being additional entities with permission to assign additional URLs to a DOI. The primary depositor deposits metadata for a DOI and creates the multiple resolution interim page, whereas the secondary depositor supplies URLs.

Steps involved in depositing Multiple Resolution DOI:

Establish permissions: the primary depositor notifies Crossref of their intention to deposit Multiple Resolution DOIs
- If needed, the secondary depositor may coordinate multiple resolution activity with Crossref. Permission from the primary depositor must be provided. (more info)
  Permission should describe in detail the content being affected, including titles and publication date ranges. Crossref will always defer to the content owner’s instructions regarding changes to DOI metadata including all assigned URLs. Content owners must recognize that when they permit secondary depositors to deposit additional URLs they will be creating additional work for their own deposit processes.
- Crossref assigns appropriate permissions to depositors and prefixes, and creates MR-only deposit accounts (if necessary).
Interim page template: an interim page template is constructed and sent to Crossref (typically this is done by the primary depositor)
Enable DOIs: the primary depositor deposits (if necessary) and unlocks Multiple Resolution DOIs.
Deposit secondary URLs: secondary depositor(s) deposits secondary URLs

Storing queries to get future results

Mon, 01 Jan 0001 00:00:00 +0000

Storing queries to get future results

If the Crossref system can’t find a suitable match for a query, it returns a result of “unresolved.” In this case, you can resubmit the same query at a later time, or you can instruct the Crossref system to store your query and email results if a match is found.

For example, suppose you are querying to find a particular article in an issue of a journal but the journal’s publisher is not a current Crossref member or has not deposited that issue yet. Initially, the Crossref system returns a result of “unresolved.” Three weeks later, the publisher deposits the article you were looking for. The Crossref systems sends an email that includes the query results to the address included in the query.

Stored queries are enabled by setting a forward-match attribute for each query item. To set the forward-match attribute, use this format:

<query key="key" forward-match="true">

The combination of the submitterID, doi_batch_id, and key in the query must be unique in order for forward matching to work.

Stored query process

1. A query is submitted with the forward-match attribute set to “true”: + show/hide example

<?xml version = "1.0" encoding="UTF-8"?> <query_batch version="1.0" xmlns = "http://www.crossref.o…"> <head> <email_address>your@email.com</email_address> <doi_batch_id>fm_429_001</doi_batch_id> </head> <body> <query key="fm_1" forward-match="true"> <journal_title>Test Publication</journal_title> <author>Anderson</author> <volume>33</volume> <issue>9</issue> <first_page>125</first_page> <year>2002</year> </query> </body> </query_batch>

2. The response to the query contains a status of ‘unresolved’ (no DOI found) and the query is stored: + show/hide example

<?xml version="1.0" encoding="UTF-8" ?> <crossref_result version="2.0" xmlns="http://www.crossref.org/qrschema/2.0" …"> <query_result> <head> <email_address>support@crossref.org</email_address> <doi_batch_id>fm_429_001</doi_batch_id> </head> <body> <query status="unresolved"> <journal_title>Test Publication</journal_title> <author>Anderson</author> <volume>33</volume> <issue>9</issue> <first_page>125</first_page> <year>2002</year> <msg>Query stored in Crossref for forward matching</msg> </query> </body> </query_result> </crossref_result>

3. A match is found after the initial query, an alert email is sent out to the email address provided in the initial query XML: + show/hide example

Here is the subject and the message of the email sent when the Crossref system eventually finds a match for the query:

Subject: Crossref stored query match: doi_batch_id= fm_429_001 ; query_key= fm_1

<?xml version = "1.0" encoding = "UTF-8"?> <crossref_result version="2.0" xmlns="http://www….-instance… "> <query_result> <head> <email_address>support@crossref.org</email_address> <doi_batch_id>fm_429_001</doi_batch_id> </head> <body> <query key="fm_1" status="resolved"> <doi>10.1038/4839201-39</doi> <issn>12345678</issn> <journal_title>Test Publication</journal_title> <author>Anderson</author> <volume>33</volume> <issue>9</issue> <first_page>125</first_page> <year>2002</year> </query> </body> </query_result> </crossref_result>

Polling for stored query results

You can also retrieve a list of stored queries that resolved within a specific date range using the following URL:

http://doi.crossref.org/servlet/downloadStoredQueries?usr=&pwd=<PASSWORD>&startDate=<FIRSTDATE>&endDate=<LASTDATE>

where:

usr is your Crossref-supplied login name.
pwd is your Crossref password.
startDate is the first date in the range (inclusive) and in the format yyyy-mm-dd.
endDate is the last date in the range (inclusive) and in the format yyyy-mm-dd.

The result is returned in XML format based on the Crossref query schema. + show/hide example

<crossref_result version="2.0" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 http://www.crossref.org/qrschema/crossref_query_output2.0.xsd">
<query_result>
<head>
<email_address>doiadmin@wiley.com</email_address>

<doi_batch_id>10.1017-311778609-13504827_2001_8_4.xml</doi_batch_id>
</head>
<body>
<query key="10.1017/S1350482701004078-BIB31" status="resolved">
<doi type="journal_article">10.3354/cr013017</doi>
<issn type="print">0936577X</issn>
<issn type="electronic">16161572</issn>
<journal_title match="fuzzy">Climate Research</journal_title>
<author match="exact">McGregor</author>
<volume match="exact">13</volume>
<first_page match="exact">17</first_page>
<year match="exact">1999</year>
<publication_type>full_text</publication_type>
</query>
</body>
</query_result>
</crossref_result>

Submission details

Mon, 01 Jan 0001 00:00:00 +0000

Submission details screen

The submission details screen is primarily used to examine the submission log for errors or warnings. Within the Crossref system interface, this screen is accessed anywhere you see a linked submission ID.

Select[Click to View] to retrieve the submission file.

Submission queue

Mon, 01 Jan 0001 00:00:00 +0000

Submission queue

After a file has been uploaded, Crossref immediately returns a confirmation that your file has been received and entered into the submission queue.

The submission queue is available via the Crossref system interface at http://doi.crossref.org. After logging in, select the Show My Submission Queue link on the opening page (or click the Submissions tab then the Show System Queue tab).

The queue results are grouped by depositor ID. Select ‘+’ under details to show filenames and queue position for each depositor.

Generally, it takes a few minutes to process a file. You then receive another email that indicates the processing results. During times of very heavy loads, however, jobs may take several hours to reach the top of the queue.

Queue management

The processing queue is serviced by several submission processors (SPs), which are started by a system administrator. Typically we run 8-10 submission processors. Each may be configured to only run jobs smaller than a certain size, jobs from specific users or to exclude jobs from specific users. Usually SPs are assigned to run jobs under 25KBytes, under 100Kbytes, under 200KBytes and then any size. This allows us to ensure that a group of extremely large files does not monopolize the active-queue.

If informed in advance, Crossref will start SPs to exclusively run jobs from an individual user. We do this along with running SPs that exclude that same user to allow a consistent level of minimum access to the active-queue. This is done when a user is going to send in a large number of files perhaps depositing back files or making a bulk update of existing DOIs. In the absence of advance notice, if we notice the presence of a large group of files we typically will adjust the queues in this manner to prevent such users from monopolizing the active-queue.

Under certain circumstances, a Crossref administrator can move jobs to the head of the queue for more immediate processing. To request this service, contact Crossref Support via email or by calling (781) 295-0072.

Submissions Administration

Mon, 01 Jan 0001 00:00:00 +0000

Submission Administration

The Submissions Administration interface displays information about a single submission or a set of submissions sent to the Crossref system. Reports can be sorted by date range, submission type, and by error or conflict status. + show/hide submission administration screen

Retrieve submission logs using a submission ID:

Access the Crossref system.
Click the Submissions tab.
Click the Administration tab.
Enter the Crossref submission ID number
Select Search to view your submission details

Retrieve submission logs without a submission ID:

If you do not have a submission ID and/or would like to view a group of submissions

Navigate to the Submission Administration tab as described above
Enter search parameters to narrow your search. You can:
- Select a date range: it is strongly recommended that a date range be entered
- Registrant: lists all prefixes associated with your login.);)
- Search by submission type: The type of submission can be selected from the drop down list, submission types are:
  - DTD Metadata: Display uploads of metadata deposited as XML per the old DTD format (discontinued 2007)
  - XML Metadata: Display uploads of metadata deposited as XML per the XSD schema
  - DOI References: Display uploads of metadata for DOI resources (aka citations)
Select Has Errorif you’re looking submissions that had deposit errors
Select Has Conflict if you’re looking for submissions that produced conflicts
Click Search to view results

Submission result output: {.h2_1}

The submission adminstration results lists:

Submission ID: link to view the submission’s details
icon: click to to view the submission’s content (deposit file)
Filename: The name of the file which was uploaded
Depositor: user who made the submission
Area: area to which the submission was made (live or test)
Submission type:
- XML Metadata: metadata deposit file
- DOI References: resource deposit file (citations, as-crawled URLs, MR URLs)
Dates: Received, Started, and Finished dates on which the submission was received and completed processing.

+ show/hide submission result screen

for more information on using submission logs, view Interpreting System Logs. For information on conflicts and how to eliminate them, see Resolving conflicts.

Tracking submissions

Mon, 01 Jan 0001 00:00:00 +0000

Using the Crossref System to track submissions

Immediately after your deposit has been submitted, the Crossref system will return a ‘Submission Accepted’ message. This message confirms that your file has been entered into the processing queue.

To view your deposit’s position in the queue:

Access the Crossref system.
Click the Show My Submission Queue link on the opening page, or click the Submissions tab and then click the Show System Queue tab.
Scroll until you see your deposit.

When your submission has been processed you will recieve an email containing the results of your submission.

Submission logs may also be retrieved by polling.
During times of very heavy loads, jobs may take several hours to reach the top of the queue.
Use the Crossref system to check your submission progress in the queue.

Transferring DOI ownership

Mon, 01 Jan 0001 00:00:00 +0000

Transferring DOI ownership

Once a DOI is assigned to a content item it should remain unchanged. When ownership of a publication is transferred from one publisher to another, the DOIs associated with the publication must also be transferred to the new owner.

Here are the basic steps involved in transferring ownership:

The acquiring publisher contacts Crossref to initiate an ownership transfer. When requesting a DOI name ownership transfer, the acquiring publisher must provide Crossref with confirmation that the disposing publisher is aware of and agrees with the ownership transfer.

New: Title transfers that have been posted to the Transfer notification list will be accepted. Otherwise, the confirmation may be an email from the disposing publisher to the acquiring publisher that is forwarded to Crossref.
The acquiring publisher sends Crossref a tab-separated list of the DOIs to be transferred and the new URLs to be associated with the DOIs:

10.5555/1234xxxx http://www.newurl.com/doi/10.5555.1234xxxx 10.5555/1234xxxy http://www.newurl.com/doi/10.5555.1234xxxy 10.5555/1234xxxz http://www.newurl.com/doi/10.5555.1234xxxz 10.5555/1234xxxa http://www.newurl.com/doi/10.5555.1234xxxa

The publisher should obtain the DOI names from the disposing publisher. If necessary, Crossref can supply a list of all the DOI names associated with the publication.
The acquiring publisher supplies Crossref with the file and its DOI name prefix. Note that only the ownership of the DOI names changes, not the prefix. If you supply new URLs, they are updated at the same time that ownership is transferred.

For more detailed information, see Title and DOI name ownership/control policies and transfer procedures (pdf).

UNIXREF

Mon, 01 Jan 0001 00:00:00 +0000

UNIXREF

Crossref’s Unified XML format (UNIXREF) returns the exact data submitted by the publisher of the DOI. This differs from other query result formats, which return data that has been processed by the Crossref system.

The UNIXREF format will return deposited citations if the depositing publisher has enabled reference distribution for their prefix. Citations will also be returned to members querying for their own deposited data.

UNIXREF schema

The majority of UNIXREF results use the unixref1.1.xsd schema (schema | documentation). Some results involving book or conference proceeding data deposited prior to a deposit schema change use unixref1.0.xsd (schema | documentation).

UNIXSD

Mon, 01 Jan 0001 00:00:00 +0000

UNIXSD query result format

Crossref’s UNIXSD query result format combines the status features available in the XSD_XML format with the full publisher records received in the UNIXREF format. In addition, UNIXSD has namespace declarations which are not available in UNIXREF.

The body of the UNIXSD query result is broken into two sections:

Immediately following the <query> will be a sequence of Crossref produced meta-metadata for the DOI. + show/hide example

<crm-item name="citedby-count" type="number">0</crm-item> <crm-item name="owner-prefix" type="string">10.1353</crm-item> <crm-item name="citation-id" type="number">25715607</crm-item> <crm-item name="journal-id" type="number">48965</crm-item> <crm-item name="book-id" type="number" /> <crm-item name="series-id" type="number" /> <crm-item name="last-update" type="date">2007-08-07 15:31:43.0</crm-item>
Publishers as-deposited XML will begin with the <crossref> element. (This is the same as the <crossref>element in the UNIXREF format). + show/hide example

<crossref xmlns="http://www.crossref.org/xschema/1.0"> <journal> <journal_metadata language="en"> <full_title>American Quarterly</full_title> <abbrev_title>American Quarterly</abbrev_title> <issn media_type="electronic">1080-6490</issn> </journal_metadata> <journal_issue> <publication_date media_type="print"> <year>1998</year> </publication_date> <journal_volume> <volume>50</volume> </journal_volume> <issue>1</issue> </journal_issue> <journal_article publication_type="full_text"> <titles> <title>&quot;Disturbing the Peace: What Happens to American Studies If You Put African American Studies at the Center?&quot;: Presidential Address to the American Studies Association, October 29, 1997</title> </titles> <contributors> <person_name sequence="first" contributor_role="author"> <given_name>Mary Helen.</given_name> <surname>Washington</surname> </person_name> </contributors> <publication_date media_type="print"> <year>1998</year> </publication_date> <pages> <first_page>1</first_page> <last_page>23</last_page> </pages> <doi_data> <doi>10.1353/aq.1998.0005</doi> <timestamp>20070206205234</timestamp> <resource>http://muse.jhu.edu//crossref/journals/american_quarterly/v050/50.1washington.html</resource> </doi_data> </journal_article> </journal> </crossref>

The meta-metadata describes attributes of the DOI that are produced by the operation of the Crossref system and should be interpreted as augmenting the publisher’s metadata.

+ show/hide full UNIXSD response

<?xml version="1.0" encoding="UTF-8"?> <crossref_result xmlns="http://www.crossref.org/qrschema/3.0" version="3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/qrschema/3.0 http://www.crossref.org/schema/queryResultSchema/crossref_query_output3.0.xsd"> <query_result> <head> <doi_batch_id>eXtyles Request 62175218</doi_batch_id> </head> <body> <query key="Q1_jrn" status="resolved"> <crm-item name="citedby-count" type="number">0</crm-item> <crm-item name="owner-prefix" type="string">10.1353</crm-item> <crm-item name="citation-id" type="number">25715607</crm-item> <crm-item name="journal-id" type="number">48965</crm-item> <crm-item name="book-id" type="number" /> <crm-item name="series-id" type="number" /> <crm-item name="last-update" type="date">2007-08-07 15:31:43.0</crm-item> <crossref xmlns="http://www.crossref.org/xschema/1.0"> <journal> <journal_metadata language="en"> <full_title>American Quarterly</full_title> <abbrev_title>American Quarterly</abbrev_title> <issn media_type="electronic">1080-6490</issn> </journal_metadata> <journal_issue> <publication_date media_type="print"> <year>1998</year> </publication_date> <journal_volume> <volume>50</volume> </journal_volume> <issue>1</issue> </journal_issue> <journal_article publication_type="full_text"> <titles> <title>&quot;Disturbing the Peace: What Happens to American Studies If You Put African American Studies at the Center?&quot;: Presidential Address to the American Studies Association, October 29, 1997</title> </titles> <contributors> <person_name sequence="first" contributor_role="author"> <given_name>Mary Helen.</given_name> <surname>Washington</surname> </person_name> </contributors> <publication_date media_type="print"> <year>1998</year> </publication_date> <pages> <first_page>1</first_page> <last_page>23</last_page> </pages> <doi_data> <doi>10.1353/aq.1998.0005</doi> <timestamp>20070206205234</timestamp> <resource>http://muse.jhu.edu//crossref/journals/american_quarterly/v050/50.1washington.html</resource> </doi_data> </journal_article> </journal> </crossref> </query> </body> </query_result> </crossref_result>

UNIXSD schema

UNIXSD results are generated using crossref_query_output3.0.xsd (schema | documentation)

This query format was introduced April 2012. All users should migrate towards using the UNIXSD as it will become the default query result format.

Crossref members may now elect to include deposited references in UNIXML query results as well as OAI-PMH results. This feature is managed on a prefix basis. Contact support@crossref.org if you would like reference distribution enabled for your prefix(es).

Updating DOIs and metadata

Mon, 01 Jan 0001 00:00:00 +0000

Updating DOIs and metadata

Once an article’s metadata has been deposited with Crossref, you may update it as often as you want at no additional fee. When making an update you must supply all the metadata for the article, not just the fields that need to be changed. During the update process the Crossref system completely overwrites the existing metadata with the information you submit, including inserting null values for any fields not supplied in the update.

To update DOIs and metadata, deposit the updated information in the same way that you would deposit any other DOI or metadata. Be sure to supply the correct DOI name in your submission to ensure that the Crossref system updates the appropriate content item. Note that the value included in the timestamp element must be incremented each time a DOI is updated.

Updating URLs

Mon, 01 Jan 0001 00:00:00 +0000

Updating URLs

A URL-only update can be performed without resubmitting metadata using a simple tab-separated list of DOIs and their new URLs.

Sample update file:

H:email=support@crossref.org;fromPrefix=10.5555;toPrefix=10.5555
10.5555/doi1 http://www.crossref.org/newurl1 10.5555/doi2 http://www.crossref.org/newurl2 10.5555/doi3 http://www.crossref.org/newurl3

Submit the update file with a Crossref Support ticket, or email the update file to support@crossref.org.

A list of DOIs for a title may be retrieved using format=doilist, details are available here.

Updating funding data

Mon, 01 Jan 0001 00:00:00 +0000

Updating funding deposits with new Registry info

The funding Registry is currently undergoing rapid growth. New funding organizations are continually being evaluated for inclusion in the Registry which at the moment is being updated almost every month. Once added a name is given a DOI making it an official Registry entry.

Updating deposited data to reflect Registry changes

Members have been including funding information in their article deposits for over a year now and many have been able to make use of the names Registry to include funding organization identifiers. In some cases an appropriate Registry identifier did not exist or a match could not be made at the time of deposit so the metadata deposited with Crossref contained just a funding organization name.

As the Registry grows these past deposits should be updated to reflect new identifiers and better Registry metadata.

getFunders API

To help members identify Registry changes that affect their prior deposits Crossref now offers a simple getFunders service which displays the Funder information for a DOI taking into account Registry changes. For example:

DOI 10.1037/0735-7036.121.3.306 was deposited on July 23, 2013 with the following funding data. This deposit identifies 5 sources of funding for the article only one of which was identified with a Registry DOI.

The API call doi.crossref.org/getFunders?q=10.1037/0735-7036.121.3.306 shows these same 5 funders with additional Registry information (in a JSON format)

{ "fundedItemDOI" : "10.1037/0735-7036.121.3.306", "funders" : [ { "prefLabel" : "SEASPACE", "isRegistryName" : "false" }, { "prefLabel" : "Walt Disney Company", "isRegistryName" : "false", "suggested" : { "isRegistryName" : "true", "identifier" : "10.13039/100004795", "prefLabel" : "The Walt Disney Company" } }, { "prefLabel" : "Soroptimist International", "isRegistryName" : "false" }, { "prefLabel" : "American Psychological Association", "isRegistryName" : "true", "depositedAsIdentifier" : "false", "suggested" : { "identifier" : "http://dx.doi.org/10.13039/100006324", "altLabels" : [ "APA" ] } }, { "prefLabel" : "American Association of University Women", "isRegistryName" : "true", "depositedAsIdentifier" : "true", "identifier" : "http://dx.doi.org/10.13039/100005280", "altLabels" : [ "AAUW" ] } ] }

This tells you that:

‘SEASPACE’ was deposited without an identifier and nothing in the Registry has changed
‘Walt Disney Company’ was deposited without an identifier but there is a Registry entry for ‘The Walt Disney Company’ which has a registry DOI
‘Soroptimist International’ was deposited without an identifier and nothing in the Registry has changed
‘American Psychological Association’ was deposited without an identifier but it does have a Registry DOI
‘American Association of University Women’ was deposited with a Registry DOI.

Updating metadata to resolve conflicts

Mon, 01 Jan 0001 00:00:00 +0000

Updating metadata to resolve conflicts

To update metadata to resolve a conflict, you deposit the new information in the same way that you would deposit any other metadata. To ensure that the Crossref system updates the appropriate content item, be sure to supply the correct DOI in your submission.

When making an update you must supply all the metadata for the article, not just the fields that need to be changed. During the update process, the Crossref system completely overwrites the existing metadata with the information you submit, including inserting null values for any fields not supplied in the update.

If the new metadata resolves the conflict, the Crossref system returns a message such as this one (which resulted from a redeposit of the metadata for DOI 10.50505/200702271050-conflict):

<record_diagnostic status="Success"> <doi>10.50505/200702271050-conflict</doi> <msg>Successfully updated</msg> <resolved_conflict_ids>352052</resolved_conflict_ids> </record_diagnostic>

Note that while submitting new metadata may resolve one or more conflicts, it might also spawn new ones. For example the following XML results indicate that submitting data for 10.5555/DOI2 resolved two existing conflicts (17 and 21) but created a new one (134).

<record_diagnostic status="Warning"> <doi>10.5555/DOI2</doi> <msg>Added with conflict</msg> <conflict_id>134</conflict_id> <dois_in_conflict> <doi>10.5555/DOI2_IN_CONFLICT</doi> </dois_in_conflict> <resolved_conflict_ids>17,21</resolved_conflict_ids> </record_diagnostic>

Double-checking that conflicts were resolved

To double-check that any conflict associated with a DOI was eliminated:

Access the Crossref system.
Click the Metadata Admin tab.
Click the Conflict tab, if necessary.
Enter the DOI ID, such as 10.1103/PhysRev.69.674.2, in the appropriate box.
Clear all the options.
Click Submit to see whether any conflict still exists.

Another way to verify the conflict was eliminated is to query for the DOI.

Updating title information

Mon, 01 Jan 0001 00:00:00 +0000

Updating or correcting title information in the Crossref system

Titles in the Crossref system are created from publisher metadata with the first deposit of a journal, book, conference proceeding, or report. The publisher determines the exact title and ISSN included in the deposit.

Title and ISSN combinations are not verified with an external agency. A check digit validation is performed on every ISSN submitted in a deposit. Once a title or ISSN is introduced into the Crossref system, a new publication with the same title or ISSN cannot be created without Crossref intervention. Deposits containing title/ISSN combinations that do not match the tite/ISSN combination in the Crossref system will be rejected.

Although publishers can’t edit titles once they have been created, Crossref administrators can adjust the following types of title information when necessary:

Add or adjust ISSNs: correct ISSN errors or add additional ISSNs not included in a submission
Add or adjust alternate spellings of titles:alternate title spellings and abbreviations are recorded for each title and used in query matching. They can be included in the <abbrev> elements in deposits or added manually by a Crossref administrator.
Correct title spelling:title spellings introduced with deposits must be correct by a Crossref administrator.
Merge titles: if two title entries have been created in error, Crossref administrators will merge the titles entries into one upon request.
Delete titles: titles submitted in error can be deleted once DOIs assigned to the title have been migrated to another title.

Title maintenance is sometimes required when a title changes ownership. View Transferring DOI ownership for more information. For assistance, contact support@crossref.org.

Uploading files

Mon, 01 Jan 0001 00:00:00 +0000

Uploading files to the system interface

The Crossref system’s web interface can be used to upload deposit or query files.

To upload files:

Access the Crossref system.
Click the Submissions tab.
Click the Upload tab, if necessary.
Click Browse and locate the file to be uploaded.
Select the file type:
- Metadata: Bibliographic data typically associated with the creation of a DOI
- Query:piped or XML queries
- DOI Query:DOI query submissions
- DOI References/Resources: XML using the DOI Resources schema which deposit references, multiple resolution data, stand alone components or additional URL information for existing DOIs
- Conflict Management: Control file that specifies how to resolve a conflict between two or more of your DOIs.

6. Click Upload.

Because DOIs are “live” in the Crossref and DOI systems immediately upon deposit be sure to have a response page in place before submitting metadata.

The Crossref system will send submission reports and query results to the email address specified in the uploaded file.

User interfaces for querying

Mon, 01 Jan 0001 00:00:00 +0000

User interfaces for looking up DOIs

Although the vast majority of query interactions with Crossref are machine-to-machine, some web-based interfaces are available for users who need to retrieve Crossref DOIs:

Crossref Metadata Search: Most Crossref query interfaces exist to return one correct DOI match, and will only return a DOI if fairly strict requirements are met. This interface is the exception - any results containing the entered search terms will be returned. Search by full citation, title (or fragments of a title), authors, ISSN, ORCID, DOI (to retrieve metadata) and more.

Simple Text Query: allows users to retrieve DOI names for journal articles, books, and chapters by cutting and pasting a reference or reference list into the query box. Registration for a free query services account is required.

Guest Query: a query interface to the Crossref system - available options include:

Fielded search: Enter bibliographic metadata into the fields to retrieve a DOI. For best results, enter all available metadata.
Author / title search:enter an author and title to retrieve a DOI
DOI query: enter a Crossref DOI into the field and retrieve the DOI’s XML in UNIXREF format.
Build an XML query: Enter query XML into the form to query if you wish to perform a quick query or experiment with query control attributes. This form is not suitable for bulk or automated querying.

Using HTTP to query

Mon, 01 Jan 0001 00:00:00 +0000

Using HTTP to Query

The most common method of submitting queries to Crossref is to have an automated service interact with the Crossref system using the HTTPS interface. Crossref strongly recommends that you group between 5 and 20 queries into a single request. This helps reduce the network transaction load on Crossref resources. These transactions use a simple HTTPS GET request with the results being returned immediately to the caller. Queries may also be processed off line in batch mode.

Synchronous HTTP queries

Synchronous queries are performed using a URL with encoded parameters as follows:

https://doi.crossref.org/servlet/query?usr=&pwd=<PASSWORD>&format=unixref&qdata=<?xml version=“1.0”?><query_batch version=“2.0”…

https://doi.crossref.org/servlet/query?pid=:<PASSWORD>&id=10.1577/H02-043

https://doi.crossref.org/servlet/query?pid=&id=10.1577/H02-043

where:

usr is your Crossref-supplied login name.
pwd is your Crossref password.
pid is your Crossref-supplied login name and password or Crossref Query Services email address.
format is the desired results format ( xsd_xml | unixref | unixsd)
*qdata *is the query data (XML is the recommended format)
id is a Crossref DOI

DOI to metadata queries may also be performed using this syntax:

https://doi.crossref.org/search/doi?pid=&format=unixsd&doi=<DOI>

where *doi*is a Crossref DOI.

To place multiple queries in one request, include them in the qdata parameter separated by %0A, as shown here:

https://doi.crossref.org/servlet/query?usr=&pwd=<PASSWORD>&qdata=|%20Natl%20Acad.%20Sci.%20USA|Zhou|94|24|13215|1997|||%0A|J.%20Mol.%20Biol.|Hagerman|260|||1996|||

Queries may be submitted in pipedor XML format. XML is recommended. + show/hide example

http://doi.crossref.org/servlet/query?usr=<USERNAME>&pwd=<PASSWORD>&qdata=<?xml version="1.0"?><query_batch version="2.0" xsi:schemaLocation="http://www.crossref.org/qschema/2.0 http://www.crossref.org/qschema/crossref_query_input2.0.xsd" xmlns="http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><head><email_address>support@crossref.org</email_address><doi_batch_id>ABC_123_fff</doi_batch_id> </head> <body> <query key="1178517" enable-multiple-hits="false" forward-match="false"><issn match="optional">15360075</issn><journal_title match="exact">American Journal of Bioethics</journal_title><author match="fuzzy" search-all-authors="false">Agich</author><volume match="fuzzy">1</volume><issue>1</issue><first_page>50</first_page><year>2001</year><article_title>The Salience of Narrative for Bioethics</article_title></query></body></query_batch>

URL encoded:

http://doi.crossref.org/servlet/query?usr=<USERNAME>&pwd=<PASSWORD>&qdata=%3C?xml%20version=%221.0%22?%3E%3Cquery_batch%20version=%222.0%22%20xsi:schemaLocation=%22http://www.crossref.org/qschema/2.0%20http://www.crossref.org/qschema/crossref_query_input2.0.xsd%22%20xmlns=%22http://www.crossref.org/qschema/2.0%22%20xmlns:xsi=%22http://www.w3.org/2001/XMLSchema-instance%22%3E%3Chead%3E%3Cemail_address%3Esupport@crossref.org%3C/email_address%3E%3Cdoi_batch_id%3EABC_123_fff%3C/doi_batch_id%3E%20%3C/head%3E%20%3Cbody%3E%20%3Cquery%20key=%221178517%22%20enable-multiple-hits=%22false%22%20forward-match=%22false%22%3E%3Cissn%20match=%22optional%22%3E15360075%3Cissn%3Cjournal_title%20match=%22exact%22%3EAmerican%20Journal%20of%20Bioethics%3C/journal_title%3E%3Cauthor%20match=%22fuzzy%22%20search-all-authors=%22false%22%3EAgich%3C/author%3E%3Cvolume%20match=%22fuzzy%22%3E1%3C/volume%3E%3Cissue%3E1%3C/issue%3E%3Cfirst_page%3E50%3C/first_page%3E%3Cyear%3E2001%3C/year%3E%3Carticle_title%3EThe%20Salience%20of%20Narrative%20for%20Bioethics%3C/article_title%3E%3C/query%3E%3C/body%3E%3C/query_batch%

Certain characters cannot be passed in a URL without causing problems. The following table lists those characters that must be URL-encoded.

Character

Name

URL code

;

%3B

Slash, virgule, separatrix, or solidus

%2F

Question mark

%3F

Colon

%3A

At sign

%40

Equals sign

%3D

Ampersand

%26

line feed

%0A

For more information on URL encoding, see URL Encoding (or “What are those %20 codes in URLs?).
DOI-to-metadata queries retrieve primarily item metadata. See Retrieving DOI info-metadata to retrieve information about a DOI such as timestamp prime/alias status.

HTTP Query Performance

There are several drawbacks to submitting synchronous HTTP queries:

A network connection is established every time an HTTP request is made. Even with HTTP keep-alive the web server disconnects the client after a short period of inactivity. The establishment of a connection with every query request can be expensive, especially for one-line queries.
User authentication on the Crossref side occurs with every HTTP request. Because most clients do not maintain a session with Crossref, the cost in terms of Crossref resources of establishing a session to enforce user access rights for every request is substantial.
Users can overcome the first two drawbacks by submitting multiple queries within the same HTTP request where queries are separated by CRLF. However, this technique presents a different problem: queries are evaluated sequentially within the same thread, which means “hard-to-resolve” queries slow down other queries within the same batch. So even though users gain in terms of network connection and Crossref authentication time, they lose the concurrence provided by submitting one-line queries.

Using HTTPS to POST files

Mon, 01 Jan 0001 00:00:00 +0000

Using HTTPS to POST Files (Upload)

Uploading files (for deposit or for bulk queries) are submitted using HTTPs post with the encType: multipart/form-data. The URL for all submissions is https:// doi.crossref.org/servlet/deposit. The following parameters are required:

Form Field

Description

Possible Values

Mandatory

Default

operation

Depends on submission type

doMDUpload: For metadata (XSD) submissions
doDOICitUpload: For DOI citations or resources submissions
doQueryUpload: For query submissions
doDOIQueryUpload: For DOI-to-metadata query submissions

doMDUpload

subType

subtype for metadata submissions

cm:For conflict management submissions

N/A

login_id

Crossref supplied login

N/A

YES

N/A

login_passwd

Crossref supplied password

N/A

YES

N/A

Content parts

fname

Submission contents

N/A

YES

N/A

SSL support was added in December 2014. All deposits should now be made using HTTPS. If you have not done so, please contact support@crossref.org to reset your password.

Sample transactions

Example using curl:

curl -F 'operation=doQueryUpload' -F 'login_id=USERNAME' -F 'login_passwd=PASSWORD' -F 'fname=@FILENAME' https:// doi.crossref.org/servlet/deposit

Example of a HTTP transaction:

POST https://doi.crossref.org/servlet/deposit?operation=doMDUpload&login_id=USER&login_passwd=PSWD HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: en-us Content-Type: multipart/form-data; boundary=---------------------------7d22911b10028e User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) Host: Myhost Content-length: 1304 Pragma: no-cache -----------------------------7d22911b10028e Content-Disposition: form-data; name="fname"; filename="crossref_query.xml" <?xml version="1.0" encoding="UTF-8"?> <doi_batch version="4.3.0" xmlns="http://www.crossref.org/schema/4.3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/schema/4.3.0 http://www.crossref.org/schemas/crossref4.3.0.xsd"> <head> ... </head> <body> <journal> .... </journal> </body> </doi_batch> -----------------------------7d22911b10028e--

For backward compatibility, the Crossref system also accepts the login_id, login_passwd, operation, and area parameters in a multi-part request. + show/hide example

-----------------------------7d22911b10028e Content-Disposition: form-data; name="login_id" atypon -----------------------------7d22911b10028e Content-Disposition: form-data; name="login_passwd" _atypon_ -----------------------------7d22911b10028e Content-Disposition: form-data; name="fname"; filename="hisham.xml"

... file contents ...

Sample program (doUpload)

A sample Java program that performs file uploads to Crossref can be downloaded from www.crossref.org/08downloads/doUpload.zip. This program allows you to upload a single file, a list of files, or a whole directory of files. Unzipping the archive will create a folder called doUpload. Open a Windows command window (Start->Run->cmd) and go to this folder and type ‘java -jar “doUpload.jar”’.

Usage: java -jar “doUpload.jar” -u username -p password -f file-name <-o upload-option>

This program uploads files to the Crossref system.If the given file has a ‘.list’ extension it is considered to be a file with a list of files to upload. Any other extension is considered a single file upload. If the file is a directory then all files in the directory will be uploaded.

The default upload option is DEPOSIT, alternatively it can be set to DEPOSIT_REFS, QUERY or DOIQUERY

Other optional args: -h host -hp port -ph proxy host -pp proxy port

-h defaults to doi.crossref.org
-hp defaults to port 80
-ph name of a proxy host if needed
-pp proxy port

File types

Users may upload a number of different file types depending on the task being addressed

XML Metadata upload
Bulk query using an XML query file
Bulk query using a pipe’d format file
Conflict resolution

Using special characters

Mon, 01 Jan 0001 00:00:00 +0000

Using special characters

Special characters are those characters that are not part of the ASCII or ISO 8859-1 (Latin-1) character sets. ASCII and Latin-1 characters can be represented in one octet (byte) of information and are displayed properly in almost all editors and viewers on most computer systems. Special characters go beyond this set and are best represented as Unicode characters. Information about Unicode is available at the Unicode Consortium’s web site, which includes a link to an interactive code chart.

Unicode is a 16-bit (two octet) format and requires viewers and editors that understand the format to allow users to work with these characters. If you view a Unicode character set file in a non-Unicode viewer, you’ll likely see gibberish such as a series of little square boxes and question marks. To further complicate matters, UTF-8 is an encoding scheme that lets you include Unicode characters in single-octet format files, like XML files. Again, you need a UTF-8 capable viewer to work with these types of files.

The XML you use to submit files to Crossref are encoded with UTF-8. The ASCII and Latin-1 sets map directly into UTF-8 so that any ASCII file can be viewed and edited in a UTF-8 compliant application, such as a browser. The issue arises when you want to include a special Unicode character in an XML Crossref file, for example, the name Müller, which contains a “u” with an umlaut.

There are two ways to include a special Unicode character in a Crossref deposit XML file:

Use a UTF-8 editor or toolwhen creating the XML and insert characters directly into the file, which results in a one or more byte sequence per character in the file.

For example, an “S” with a háček (Š) has a decimal value of 352 which is 160hex. This value converts to the UTF-8 sequence C5,A0 in hex. You can create a small XML file in which you insert this two-byte sequence (shown here between the <UTF_encoded> tags).

<?xml version="1.0" encoding="utf-8" ?> <start> <UTF_encoded>Š</UTF_encoded> </start>

The character displays properly in a browser but if you save the XML source and try to view it in certain editors, it will not display correctly.
Encode the special character using a numerical representation. This is the preferred approach and is implemented by constructing an entity reference in the XML that is the numerical value of the character. For example, <surname>Šumbera</surname> includes the special character “S” with a háček (Š).

Character entities

XML based on schema does not support named character entities. For example, é or – are not allowed . In order to include these characters you must use their numerical representation, é or – respective. These are called numerical entities as signified by the presence of the ‘#’ character. The ‘x’ following the pound sign indicates the value is in hex, as opposed to decimal if the ‘x’ were omitted. All entities must end with the ‘;’ character.

Character numerical values may be found on the Unicode web site at The Unicode Character Code Charts.

Face markup

Some style markup is supported by the Crossref schema but we recommend minimal use of this capability. The metadata being deposited with Crossref is primarily intended to support DOI lookup and retrieval. Only when style markup is essential to the meaning of the text should it be used.

For more information about Unicode and UTF-8, see UTF-8 and Unicode FAQ for Unix/Linux and The ISO 8859 Alphabet Soup.

Using the match attribute

Mon, 01 Jan 0001 00:00:00 +0000

Using the match attribute

The Crossref query engine operates by evaluating several logic rules in series. Each rule focuses on certain fields in the query with the first rule processing the entire query. If any rule returns a single DOI as its output, this DOI is taken as the result for the query, and rule processing terminates.

match attribute

In an XML query you can exercise some control over how the query engine works by using the match attribute that is available on many query elements. Note: multiple values may be assigned as in match=“optional fuzzy”. Typical uses:

match=“fuzzy” => fuzzy matching is allowed but the field is not optional, it must be matched
match=“optional fuzzy” => a rule may drop the field altogether or use fuzzy matching
match=“exact” => field must be matched and no fuzzy matching is allowed
match=“” => same as match=“exact”

Below is an explanation of what each option achieves.

Fuzzy

Instructs the query engine to apply its fuzzy comparison logic for this field

Optional

In most cases ‘optional’ is a default property. Using a value that excludes optional (e.g match=“”) tells the query engine that this field is not optional and must be present, and matched, for a DOI match to occur.

Exact

Instructs the query engine to not apply any of its fuzzy comparison logic. This is the same as match=“” (which means not optional and not fuzzy). Using ‘exact’ is not compatible with optional, or fuzzy.

match=“exact optional” is illegal
match=“exact fuzzy” is illegal
match=“exact optional fuzzy” is illegal

Null

Instructs the query engine to match on the query element if it is not present in the metadata. When using this option it makes no sense to provide an element value (e.g. the proper style would be <author match=“null”/>

Allowing multiple matches, Author/title secondary query

Verifying your XML

Mon, 01 Jan 0001 00:00:00 +0000

Verifying your XML

If you are new to Crossref or intend to deposit a new content type, it is recommended that you verify the format and structure of an XML file before submitting it as a deposit to the system. Using these methods is quicker than verifying your XML by trial and error.

You can validate your XML by:

1.Using the XML Parser on the Crossref web site

When you send data to the XML Parser no processing occurs. If the files parses successfully you will see a count of the number of DOIs found in the file. Failures will be displayed as errors generated by the Xerces parser.
The validator will validate against all Crossref schema but the most recent schema version (currently 4.3.6) is recommended.

Best for: quickly validating a few files

2.Using the test system at http://test.crossref.org

Crossref maintains a test system at http://test.crossref.org. The test system functions identically to our live system but uses a test database and does not register DOIs with Handle. To use, direct your browser or deposit program to test.crossref.org instead of doi.crossref.org.

Best for: testing large numbers of files or new titles

If you are a new Crossref member the test database might not be have been updated with your login credentials or prefix. If you are denied access, contact support@crossref.org.

Viewing conflicts using the web interface

Mon, 01 Jan 0001 00:00:00 +0000

Viewing conflicts using the web interface

If you know the submission ID, conflict ID, or DOI involved in a conflict, you can view details about it using the Crossref web interface.

If you submit an item to the Crossref system that creates a conflict, the system notifies you in the submission log it returns by email. For example, this email:

<record_diagnostic status="Warning"> <doi>10.1103/PhysRev.69.674</doi> <msg>Added with conflict</msg> <conflict_id>865</conflict_id> <dois_in_conflict> <doi>10.1103/PhysRev.69.674a</doi> </dois_in_conflict> </record_diagnostic>

indicates that 10.1103/PhysRev.69.674 is in conflict with 10.1103/PhysRev.69.674 and that the conflict has been assigned an ID number of 865.

Because you know the conflict ID, you can view detailed information about it within the Crossref system. To do so:

Access the Crossref system.
Click the Metadata Admin tab.
Click the Conflict tab, if necessary.
Enter one of the following and select the appropriate options:

Submission ID:

Unresolved – Displays only unresolved conflicts
Primary/Alias – Displays*conflicts that have been resolved in prime/alias pairs*
Auto– Displays only conflicts that the Crossref system automatically resolved only
Resolved – Displays only unresolved conflicts
Submission is conflict source – ID entered is for the submission that caused the conflict
Submission is NOT conflict source – ID entered is for a submission that is involved in a conflict but not the cause of it

Conflict ID:

Show consolidated conflicts – Displays the conflict IDs but not the details
Show auto-resolved conflicts – Includes in the list conflicts that the Crossref system automatically resolved

DOI ID

Show consolidated conflicts – Displays the conflict IDs but not the details
Show auto-resolved conflicts– Includes in the list conflicts that the Crossref system automatically resolved
Unresolved – Displays only unresolved conflicts****
Primary/Alias – Displays conflicts that have been resolved in prime/alias pairs
Auto – Displays only conflicts that the Crossref system automatically resolved only
Resolved– Displays only unresolved conflicts

Click Submit to see the DOIs associated with the conflict.

Click the conflict ID to see the DOIs involved, the Submission IDs involved, the status, and the metadata for the items involved in the conflict.

Web deposit form

Mon, 01 Jan 0001 00:00:00 +0000

Depositing using a web form

Crossref provides an easy-to-use HTML form for registering DOIs. The form requires no knowledge of XML and is suitable for a small number of deposits. You can use this web deposit form to register DOIs for journals and articles, books and chapters, conference proceedings, and reports.

When depositing, enter all available metadata to ensure successful query matching

To use the web deposit form:

Navigate to the web deposit form. (on the Crossref web site select “Web deposit form” under Technical Resources)
Select the type of content you want to deposit: Journal, Book, Conference Proceedings, Report, or NLM File
Enter the appropriate information for the type of content you selected.
- Journals: register a journal-level DOI only or DOIs for each article within a given issue. Only one issue can be deposited at a time. + show/hide details
  Journal-level information:
  Title*: Journal title
  Abbr*: Journal abbreviation (if the journal has no abbreviation, enter the journal title
  Journal DOI and URL: the DOI and URL for the journal itself (optional for article deposits)
  Print ISSN or Elect ISSN*: only one ISSN is required
  Volume and Issue: optional, but should be included when available
  Issue DOI and URL: DOI and URL for the issue being deposited (optional)
  Publication date: Year is required, month and day are optional
  
  Select ‘Submit Journal DOI’ if you are submitting only journal or issue-level DOIs. Select ‘Add Articles’ to enter article metadata.
  
  Article information:
  *Title*:*article title
  First author: select ‘add contributor’ to add additional authors or editors. (authors are not required but strongly recommended)
  *DOI and URL*:*DOI and URL for the article
  First page and Last page: not required but strongly recommended
  
  Select ‘Add Another Article’ to add additional articles, ‘Finish’ to complete your deposit, and ‘Cancel’ to return to the previous page.
- Books: register both book- and chapter-level information. Select ‘Submit Book DOI’ to deposit a title-level DOI, or select ‘Add Chapters’ to enter metadata for chapters attached to the book being deposited. For series and sets, only one volume can be deposited at a time. + show/hide details
  Monograph:
  Title*: title of the book
  Book DOI and URL: book-level DOI and URL
  Contributors*: select ‘add contributor’ to add additional authors or editors. Deposit all authors when available.
  Publisher*
  ISBN*: select ‘NO-ISBN’ if no ISBN exists for the book
  Edition: include only edition number
  Publication date*: Year is required, month and day are optional
  
  Book Series:
  Series Title*: series-level title
  Series ISSN*
  Series DOI and URL: DOI and URL for the book series (optional)
  Series contributors: series-level contributors only
  Title*: volume-level title
  Book DOI and URL: volume-level DOI and URL
  Contributors*: volume-level contributors (surname required)
  Publisher*
  ISBN*: select ‘NO-ISBN’ if no ISBN exists for the book
  *Volume:*volume number
  *Edition:*include only edition number (1 instead of 1st ed., for example)
  Publication date*: Year is required, month and day are optional
  
  Book Set:
  Set Title*: set-level title
  Set ISBN: set-level ISBN (optional)
  *Set DOI and URL:*set-level DOI and URL (optional)
  Set contributors: set-level contributors only
  Title*: volume-level title
  Book DOI and URL: volume-level DOI and URL
  Contributors*: volume-level contributors (surname required)
  Publisher*
  ISBN*: select ‘NO-ISBN’ if no ISBN exists for the book
  *Volume:*volume number
  *Edition:*include only edition number (1 instead of 1st ed., for example)
  Publication date*: Year is required, month and day are optional
  
  Chapter:
  Title*: title of the chapter
  Component number: If you are submitting data for a monograph that simply has “Chapter 1”, “Chapter 2”, etc., you should put this information in component_number.
  Contributors*: chapter-level contributors
  DOI and URL*: chapter-level DOI and URL
  First page and Last page: not required but strongly recommended
- For conference proceedings, enter event and conference paper information. Select ‘Add Papers’ to enter metadata for conference papers. + show/hide details
  All conferences:
  Conference title*
  Conference acronym
  Conference date
  Proceedings title*
  Publisher*
  ISBN*: select ‘NO-ISBN’ if no ISBN exists
  DOI and URL: proceedings-level DOI and URL
  Publication date*: Year is required, month and day are optional
  
  Conference series only:
  Series title*
  Series ISSN*
  Series DOI and URL: optional
  
  Conference paper:
  Title*: title of the conference paper
  Contributors: not required but strongly recommended
  DOI and URL*: paper-level DOI and URL
  First page and Last page: not required but strongly recommended
  Publication date*: Year is required, month and day are optional
- For reports:Select ‘Submit Report DOI’ to deposit a single report DOI, or select ‘Add Content Item’ if the report contains multiple chapters or papers. + show/hide details All reports:
  Title*
  Report DOI and URL: optional, required if content_item is not being deposited
  Contributors*
  Publisher*
  Institution Information (name, acronym, place, department, contract number, edition): all optional
  Publication date*: Year is required, month and day are optional
  
  Report series:
  Series Title*
  Series ISSN*
  Series DOI and URL
  Series contributors: series-level contributors only
- NLM upload: To upload an XML file built according to the NLM DTD (publishing tag set) select NLM file, use the Browse function to locate NLM XML file and enter login, contact, and DOI information. If the DOI and URL are not contained within the XMLDOI and URL would be inserted as: <article-meta> <article-id pub-id-type=‘doi’>10.1234/abcdef</article-id> <self-uri>http://server.address.com/someplace.html </article-meta>. Enter them on the form and click Upload NLM Data to submit.
- Supplementary metadata upload: funding and license metadata may be uploaded in .csv format.
Enter your username and password and email address and select Deposit.

After you have filled out and submitted the web deposit form, your upload will be processed by the Crossref system. You will receive two emails: a submission report and an XML file.

Review the submission report to verify your deposit was processed successfully.
The XML file is created from the information submitted through the web deposit form. If changes need to be made to your deposit, you can edit and submit this XML using the Crossref system.
Your Crossref username (your login name) and password will be required at the end of this process to submit the data to the system. Please ensure your browser allows JavaScript so the data validation will function properly.
We strongly encourage you to save the XML file sent to you post-deposit, as using it is the easiest way to perform updates of the data entered using the form. Instead of reentering your metadata, you can edit the XML and resubmit using the system interface.

What are conflicts?

Mon, 01 Jan 0001 00:00:00 +0000

What are conflicts?

When two (or more) DOIs share identical metadata, Crossref considers the DOIs to be in conflict. Conflicts generally occur for two reasons:

Deposited metadata isn’t sufficient to distinguish among DOIs. For example, items like ”Book Reviews”, “Letters” and “Errata” often share a single page and have no author
Two or more DOIs have the same metadata. In this case, either the DOIs are missing titles and/or sequence numbers, or they have the same metadata, same titles, and/or same sequence numbers.

Review sample conflict scenarios for specific examples.

Conflicts compromise query results. With many forms of querying, no match will be returned if the Crossref system is not able to conclusively identify a single DOI to match the metadata in a query. To prevent this problem, conflicts should be resolved as soon as possible.

A DOI Conflict Penalty Fee of \$2.00 per conflict may charged at Crossref’s discretion.

What is a DOI

Mon, 01 Jan 0001 00:00:00 +0000

What is a DOI?

Similar to a bar code for a physical object, a Digital Object Identifier (DOI) is a unique alphanumeric string assigned to a digital object, such as an electronic journal, article, report, or thesis. Each DOI is unique and serves as a stable, persistent link to the full-text of an electronic item on the Internet. Unlike a URL, a DOI doesn’t change over time; even if the item moves to a new location, the DOI stays the same.

DOIs are the only widely adopted persistent identifier for scholarly works. DOI names appear in printed materials and online as links.

A DOI name consists of two segments:

Prefix: a unique numeric string beginning with the numeral 10 assigned by Crossref to the publisher that submitted the information about the digital object

Suffix: an alphanumeric string or series of strings used internally by the publisher to identify the digital object.

In this sample DOI name: 10.1006/jmbi.1995.0238 - 10.1006 is the prefix (in this case, for the publisher Elsevier) and jmbi.1995.0238 is the publisher-assigned suffix for the particular item (in this case, indicating that it is from the *Journal of Molecular Biology*and was published in 1995).

Print, PDF, and HTML versions of the same digital item all use the same DOI names. Generally, a DOI name points to the item in a single location; however, with multiple resolution, it is possible to point to more than one location.

For a more extensive discussion of DOIs, see The DOI Handbook (pdf) on the Digital Object Identifier System web site.

Not all DOIs are Crossref DOIs - use the DOI RA toolto identify the DOI registration agency.

Who uses Crossref DOIs

Mon, 01 Jan 0001 00:00:00 +0000

Who uses Crossref DOIs and why?

The four primary types of Crossref DOI users are publishers, affiliates (including agents and journal hosting platforms), libraries, and individual researchers. Using Crossref DOIs offers significant benefits to each of these groups:

Publisher + show benefits

Link persistence: Unlike URLs, DOI links continue to function even if content moves or changes ownership.
Content visibility and accessibility: Crossref helps drive traffic to content by making it discoverable for linking and easier to link to.
Centralized linking agreement: A single agreement with Crossref serves as a linking agreement with all participating publishers.
OpenURL integration: Crossref member publications are automatically OpenURL-enabled via the DOI name.
Added value: Linking enriches the end-user experience, the scholarly research process, and the utility of published resources.
Internal as well as external linking: Once a publisher registers all of its content with Crossref, DOIs can be used for internal linking as well.
Cost-effectiveness: One annual fee covers all types of content.

Affiliate + show benefits

Increased usefulness: Linking directly to full-text enhances the utility of indexes.
Additional services: Offer Crossref/DOI implementation as part of hosting services.
Transparency: Provide seamless integration of secondary, abstracted, or aggregated materials with primary literature
Centralized linking agreement: A single agreement with Crossref serves as a linking agreement with all participating publishers.
Cost-effectiveness: Expanded publication coverage without increased cost.

Library + show benefits

Usage and accessibility: Navigation at the item and citation level leads to increased usage of electronic resources.
Availability: DOI links can extend access to content not owned in the current collection.
Reliability and longevity: DOI links are persistent; they do not change even when the content item’s location does.
Localized linking: Libraries can set up and use a local link resolver to point to items already in their own collection or to which they have a subscription.
Cost-effectiveness: Libraries can retrieve DOI names and metadata at no charge.

Researcher + show benefits

Ease of use: It only takes a click or two to get to the full text, through open-access, through pay-per-view services, or as an authenticated subscriber.
Availability and accessibility: DOI names provide access to over 19 million content items available from over 1,500 publishers and societies.
Cost-effectiveness: Individual researchers pay no fees to access content using DOI names.

Crossref publishers and titles

Working with your Resolution report

Mon, 01 Jan 0001 00:00:00 +0000

Working with your Resolution Report

The resolution report, delivered monthly, gives publishers valuable insight into DOI usage. It also is a good resource for identifying potential problems with either depositing practices or linking. The resolution failure rate is of particular interest as it allows a publisher to compare their failure rate with that of other publisher members. The ideal failure rate is 0% but realistically 2-3% is the normPublishers who are new to Crossref or who have created a small number of DOIs may have a high failure percentage (for example, a publisher with 1 failure and 9 successes will have a 10% failure rate).

A .csv file containing a list of all failed DOI resolution attempts for the month is attached to each report. This file should be reviewed to identify problems with both linking and deposits. Any DOIs with a high number of failures should be examined closely. Significant changes in your resolution failure rate should be taken seriously as well.

Troubleshooting tips:

If you have a high number of failures for a DOI you have not published, Google the DOI to see if it is readily available online - it is possible that the DOI is being linked incorrectly.
If an active DOI appears on your failed DOI list, review when the DOI was deposited. For example, if the DOI was deposited on the 18th, any resolution attempts prior to the 18th will appear on your report.
The Handle resolver supports URL-encoded DOIs.The resolution logs sometimes misrepresent the encoded characters. As a result, some badly encoded DOIs will appear in your resolution log as correctly encoded DOIs. This typically happens when an already-encoded DOI is mistakenly encoded again. For example, DOI 10.5555/example would be correctly encoded as 10.5555%2Fexample (the / is encoded as %2F). If the DOI is encoded again, the % in the DOI becomes %25, making the DOI 10.5555%252Fexample. This DOI will not resolve but will appear in the failed DOI report as 10.5555%2Fexample (a valid DOI).
Crossref can run additional reports if necessary - contact support@crossref.org for details

Not all DOIs included in the failed DOI .csv are legitimate DOIs ( DOIs that have been published). Possible reasons for DOI failure include:

Undeposited DOI:a DOI has been distributed but not deposited - any DOIs that have been published should be deposited immediately to prevent future resolution failures.
User error: a user can sometimes make mistakes when typing or cutting-and-pasting DOIs. These failures will appear on your report and for the most part can be ignored - if your report frequently includes what you determine to be user errors, review how your DOIs are displayed. See common user errors

0 vs. 0, l vs. 1: Most DOI resolutions are generated by users clicking on a link, but (particularly for those of you who publish DOIs in print) users do type them in. If your DOI failures often contain DOIs with 0 being confused with O, or l with 1, consider changing your DOI suffix. Long strings of letters and numbers can cause problems as well.
DOIs ending with .: One of the more common DOI failures is an > otherwise viable DOI with a ‘.’ appended. These usually are linked > from references that end with a ‘.’
DOIs with special characters instead of -:this commonly happens > when a user cut-and-pastes a DOI from a PDF.
DOIs with special characters:end users often are not aware of > problems caused by linking with special characters such as <,>, > #, and +. Crossref does not currently accept deposits with > special characters but did in the past.
DOI publication and deposit are out of sync: if you publish DOIs (print or online) prior to depositing them, any resolution attempts will appear in the report. DOIs should be published and deposited as close to simultaneously as possible. It’s often not possible to do so, but the interval should be hours or a day, not days or weeks.
Linking issues: occasionally a DOI is the victim of a bad link - if the link is under your control, please change it. If not, alert the link creator (if possible).

XML Journal List (mddb.xml)

Mon, 01 Jan 0001 00:00:00 +0000

XML Journal List (MDDB.XML file)

The MDDB.xml file can be downloaded here (file is > 5MB). The file includes all Journal Titles, Title abbreviations, ISSNs, Year range, Volumes, and the assigned DOI prefix.

<journal title="ISPRS Journal of Photogrammetry and Remote Sensing"abbr="ISPRS Journal of Photogrammetry & Remote Sensing|ISPRS J Photogramm Remote Sens" issn="09242716|" years="1989-2007" volumes="44-62" prefix="10.1016"/> <journal title="Il Farmaco" abbr="Farmaco" issn="0014827X|" years="1998-2005" volumes="53-60" prefix="10.1016"/>

Journal Title and coverage information is also available as a downloadable .csv (file is > 5MB)

query_services

Mon, 01 Jan 0001 00:00:00 +0000

Query Services

Crossref provides various web interfaces for key query services. Registered Crossref Members, Libraries and Affiliates may use these interfaces with their previously supplied system account credentials. If you are not a Crossref member with account credentials, you may register for an account here. Query Services accounts are available at no charge for non-commercial use. Detailed terms and conditions are available on the account request form.

Crossref Query interfaces are:

track submissions via HTTPS

Mon, 01 Jan 0001 00:00:00 +0000

Retrieve submission results via HTTPS

After your submission has been processed, a submission report will be emailed to the address provided in the submission.

It is also possible to retrieve the results of submission processing or the contents of a submission at any time through this URL:

https://doi.crossref.org/servlet/submissionDownload?usr=&pwd=<PASSWORD>&doi_batch_id=<DOI BATCH ID>&file_name=<FILENAME>&type=<TYPE>

where:

*usr*is the Crossref-supplied login name
pwd is the Crossref-supplied password
*doi_batch_id*is the DOI batch ID you supplied in the XML deposit file
file_name is the name of the file that you submitted
type is the type of data requested (this field is mandatory)
Use result to retrieve submission results (deposit log)
Use content to retrieve the XML file

You can track a submission by its doi_batch_id or by its file_name. In either case, only the first match is returned. To use this feature effectively, make sure each tracking ID (doi_batch_id or file_name) is unique.

Only the first match is returned. So, in order to use this feature effectively, it is the publisher’s responsibility to make sure that each tracking ID (doi_batch_id or file_name) is unique.
The main difference between using doi_batch_id and file_name is that doi_batch_id is inserted into the database after the submission has been parsed. Using file_name is preferable because submissions in the queue or in process can be tracked before deposit. Non-parse-able submissions can also be tracked using this method.
You may also use the system to retrieve and view submission reports.