As a Crossref member and book registrant, I'd like a clearer error message for failed book submissions when other DOIs have been registered against a matching title and ISBN

Oxford University Press has flagged this submission error message and rightly pointed out that the error message isn't all that helpful in diagnosing the problem. Here's an example submission: https://doi.crossref.org/servlet/submissionAdmin?sf=detail&submissionID=1508458432

And, the error message:

<doi>10.1093/wentk/9780190262754.001.0001</doi>
      <msg>ISBN "9780190262754,9780197569221" has already been assigned, ISBN assigned to other title DOI: 10.1093/wentk/9780190262754.001.0001 ISBN:9780190262754,9780197569221</msg>

The issue here is that DOI 10.1093/wentk/9780190262754.001.0001 is NOT the DOI that has already been assigned for this (book) title-level DOI. The DOIs registered against this book cite ID are:

  • 10.1093/oso/9780198801085.003.0011
  • 10.1093/oxfordhb/9780199300983.013.41
  • 10.1093/oxfordhb/9780195366556.013.0007

Returning those three DOIs for this error message would be much more helpful and less confusing for the member, and would help reduce toil, since the support team handles many of these requests.

Screen_Shot_2021-10-06_at_2.56.23_PM

Is this a bug? It seems like the error message was written to pull in the existing DOIs registered against the ISBN(s) registered in the book cite ID, but instead is just repeating the failed DOI in the submission.

How urgent

Moderate urgency. Would help with some issues of toil for the support team.

Definition of ready

  • Product owner:
  • 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
    • Respond to and close Zendesk 384911
  • 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.

Notes