Patricia Feeney Aug 27 • 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 email@example.com.
Patricia Feeney Jun 4 • 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 Feb 5 • Announcements
As-crawled URLs for CrossCheck indexing can now be deposited with a CSV upload, details are here: http://help.crossref.org/as-crawled-csv-upload
Patricia Feeney Jan 28 • Announcements