Patricia Feeney August 27, 2015 Support Announcements

We’ve begun a behind the scenes effort to make conflict identification and resolution easier to manage.  When a conflict is created, it is assigned a ‘conflict ID’ that identifies that specific instance of a conflict (meaning: multiple DOIs have been identified as having identical metadata).  If either DOI is re-deposited with the same metadata, a new conflict ID is created.  If a conflict is flagged as ‘resolved’ (meaning no DOI is flagged as the ‘prime’ DOI), subsequent deposits of the DOIs will re-activate the conflict status and trigger a new conflict ID.

We are in the midst of consolidating existing conflict IDs into a single ID, and identifying and resolving situations where a DOI conflict has been resolved in some way but reopened. Most conflicts are straightforward, but when multiple DOIs and instances of conflict creation are involved, our conflict reports and resolution processes become unwieldy. Ultimately the important thing to identify is what DOIs are not distinct, not when or how many times the conflict has been introduced and re-introduced.

At the moment two DOIs updated with identical metadata over time can create a situation like this (displayed in our conflict management interface) :


 While amusing, this report does not accurately reflect what is actually happening:  two DOIs are in conflict and the conflict has been flagged as 'resolved'.  After our conflict consolidation process has completed, this conflict will be assigned a single conflict ID and the correct status of ‘resolved’:


The most recent conflict status will also be reflected in conflict reports, and in submission logs when conflicts are created (or re-introduced). Those of you who regularly investigate and resolve any deposit warnings will hopefully find this a welcome change. The consolidation of conflicts will be reflected in the DOI history report.   This process should be a seamless improvement for members with DOI conflicts, making conflicts easier to identify and resolve, but if you run into any issues or have questions please contact

Patricia Feeney June 4, 2015 Support Announcements

Our deposit schema allowed multiple FundRef programs (<fr:program>) within CrossMark deposits. This was an oversight, only one <fr:program> should be deposited.  The <fr:program> element can contain multiple groups of funder information within a "fundgroup" assertion as described in the FundRef documentation.

Our deposit schema is being updated to enforce this.  If you have been depositing FundRef data with multiple programs, please redeposit as this affects how CrossMark displays your funding information.

Patricia Feeney February 5, 2015 Support Announcements

As-crawled URLs for CrossCheck indexing can now be deposited with a CSV upload, details are here:

Patricia Feeney January 28, 2015 Support Announcements

The matching for the getFunders API has been improved. The FundRef Registry is continuously updated with new funding organizations. The getFunders API returns Funder information deposited for a DOI, as well as any additional Funder information that may not have been established at the time of deposit. 
For example, displays funder information in JSON format for DOI 10.1109/JPHOT.2014.2331233.
The funder name ‘NSF’ has been deposited for this DOI. This funder name is too ambiguous to make a match, the getFunder API displays all available funders related to ‘NSF’.

Patricia Feeney January 7, 2015 Support Announcements

CrossRef strongly advises that all depositors move to HTTPS. Once HTTPS has been implemented by your organization, you should change passwords for any deposit accounts that have been used with the non-SSL interface.

Please contact to coordinate password changes.

Note: We will continue to support a non SSL interface but we strongly encourage anyone making deposits or services requiring a deposit enabled login to switch to SSL. Query transactions can continue to use non SSL but be sure to use a separate account so that deposit capable credentials are not exposed to clear text transmissions.