Feature request from member: Tools for auditing deposits, possibly as additional "updated" date in REST API
As a Crossref member, I want a way to audit my past metadata deposits on a large scale and ensure that we're not missing any intended updates.
What
One of our members was trying to use the from-update-date filter in the REST API to return a list of works that they, as the publisher, had submitted metadata updates for after October 1st 2021.
However, they identified at least one DOI in this query's results that they knew for sure that they had not updated since 2020: 10.1108/S1521-6136(2009)0000013019
I explained that there are other things that can cause a DOI to be 'updated' in the REST API, other than the publisher submitting an updated metadata deposit. Most commonly, that's a result of a new citation match for that DOI or an update of a citing work's metadata. In the case of 10.1108/S1521-6136(2009)0000013019 the metadata for 10.1146/annurev-lawsocsci-102811-173923 was updated on October 13th. And because 10.1146/annurev-lawsocsci-102811-173923 cites 10.1108/S1521-6136(2009)0000013019, it triggered a reindex of 10.1108/S1521-6136(2009)0000013019 as well.
So, that leaves the member without any way to retrieve metadata for only those works that they actually submitted updated metadata deposits for in a given time period.
We have options in the admin tool for searching the deposit history of a singe DOI, or the full deposit history for a given user over a given date range, but there's no way to refine those searches at scale, the way that an API might allow.
Why
The member explained
We have a workflow which includes publication on acceptance, followed by an update when the content gets assigned to an issue and has print dates, page numbers, etc., and I’m trying to audit what’s deposited and when.
and
We have experience of occasional ‘silent failures’, where something hasn’t deposited with Crossref, but in a manner which means that none of the usual reporting systems flag up that something has gone wrong. That kind of thing is hard to spot unless you can compare what was expected to be sent with what was actually received.
How urgent
Definition of ready
-
Product owner: @SaraBowman -
Tech lead: -
Service:: or C:: label applied -
Definition of done updated -
Acceptance testing plan: -
Weight applied
Definition of done
-
Unit tests identified, implemented, and passing -
SONAR on merge request branch checked by tech lead -
SONAR on merge request branch checked by reviewer -
Code reviewed -
Available for acceptance testing via a staging URL, or otherwise -
Consider any impacts to current or future architecture/infrastructure, and update specifications and documentation as needed -
Knowledge base reviewed and updated -
Public documentation reviewed and updated -
Acceptance criteria met -
AC 1 -
AC 2
-
-
Acceptance testing passed -
Deployed to production
Prior to and during Backlog Refinement, consider the potential impacts this user story may have on the following areas:
- Billing/costs
- Internal documentation
- External documentation
- Schema
- Outputs
- Operations
- Support & Membership experience
- Outreach & Communications
- Testing
- Internationalization
- Accessibility
- Metrics, analytics, reporting
Additional details about the above items can be found here.