Ticket of the month - January 2022 - on the importance of submission IDs

Content Registration
, , , ,
1

One of the most common questions into the support desk looks something like this:

Hello, I attempted to register my DOIs for my recent journal issue, but they’re not resolving. Can you help?!

In this form, with some digging, we can usually provide you information about the problem, as long as the member writing into support has contacted us on an official email address associated with their account. If not, we’re at a dead end and will be returning to you for basic information about your account.

At a minimum, in order to start our investigation, we need a username and/or prefix.

But, the absolute best piece of information you can provide us with is your failed submission ID. Each attempted submission gets its very own submission ID. We return it in the email we send you for your submissions. It looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<doi_batch_diagnostic status="completed" sp="ds5">
   **<submission_id>1519232661</submission_id>**
   <batch_id>000032</batch_id>
   <record_diagnostic status="Success">

With that submission ID, our support team can: 1) compare exactly what was submitted in the failed deposit with what has been previously registered with us for the title in question, and 2) in most cases, after addressing the problem, reprocess the failed submission (saving you from having to resubmit it to us).

While we’re here, I’ll briefly mention the cause of many submission failures: it’s inconsistency.

You see, our admin tool performs some rigid title-level checks during processing. We perform those rigid checks to enforce consistency in your metadata records. Thus, if Member A initially registers their new journal (ISSN 1234-5678) with the journal title Journal of Things and Stuff for, say, their first issue, but, then, the following month, submits the journal title to us as Journal of Things & Stuff that small difference between the word and and the & in the journal title will cause the following month’s submission to fail with an error message that looks like this:

<record_diagnostic status="Failure" msg_id="22">
<doi>all doi's under the current journal element</doi>
<msg>ISSN "12345678" has already been assigned, issn (12345678) is assigned to another title (Journal of Things and Stuff)</msg>
</record_diagnostic>

There are a few exceptions (e.g., an oxford comma in a title), but, generally speaking, if your title-level metadata does not match EXACTLY on a resubmission against that title (journal, book, conference), you’re likely to encounter submission failures, like the example above. The same is true of journal-title-level DOIs. If those are submitted to us inconsistently, there will be submission failures.

This is where the submission ID comes into play. If you have a failed submission, our support team is eager to assist, but it can be challenging to locate failed submissions in our admin tool. For instance, we cannot search for DOIs that have never been successfully registered. We can view the successful submission history of a DOI, but we don’t log those failures against that DOI. We simply reject them. Thus, if Member A contacts us and asks something like “Why haven’t my DOIs 10.5555/ja78dz and 10.5555/p.0a05x been registered yet,” we typically can only confirm that they are unregistered.

Now, for some members who are sending us a single deposit every week or month, reviewing submission history isn’t a daunting task. Our support team may take a quick peek at your submission history and find that the failed submission is right atop the list. But, many of our members submit hundreds and thousands of submissions per day. Trying to find a failed submission without a submission ID for a member with a very active submission history is a needle-in-a-haystack situation. In those cases, since we do not have a submission ID, it’s not possible for us to make a comparison between our records and the metadata submitted to us, so we’re only able to see one side of the issue.

In my example above, I could tell Member A that ISSN 1234-5678 was previously registered and established as a record in our admin tool as: Journal of Things and Stuff and that’s what we were performing our journal-title-level checks against, but I couldn’t definitively then say that the issue was between the use of the word and and the &.

Thanks for reading,
Isaac

1 Like