Duplicate DOIs keep being minted

Content Registration
, , ,
1

As has been noted elsewhere on this forum (e.g., Double trouble with DOIs) duplicate DOIs are a thing, and I seem to be finding more of them. A typical use case is a publisher taking over another journal and minting its own “branded” DOIs for content that already has DOIs.

This is intensely frustrating and completely breaks the rationale for DOis in the first place. A recent example is 10.1139/w00-145 and 10.1139/CJM-47-3-213. These are DOis for the same article " Polyphasic taxonomy of the basidiomycetous yeast genusRhodosporidium :R. azoricum sp. nov." and metadata for these two DOis is available in CrossRef’s search engine: https://0-api-crossref-org.libus.csd.mu.edu/v1/works/10.1139/cjm-47-3-213 and https://0-api-crossref-org.libus.csd.mu.edu/v1/works/10.1139/w00-145.

Any third-party that depends on DOIs as the definitive, persistent identifier for an article will be affected by these sorts of changes, such as tools building citation links, tracking article metrics, or including citations in projects such as Wikidata.

Can CrossRef please explain how this continues to happen, and what steps it is taking to encourage members to avoid this situation? It seems a fundamental goal of CrossRef - one DOI per article - is being continually broken by publishers more intent on have DOIs they like the look of rather than supporting the goal of persistent identifiers that do not change, regardless of ownership of the content.

2

Another example, this time for The Lichenologist: Studies on The Lichen Genus Sticta (Schreber) Ach.: I. Southern South American Species | The Lichenologist | Cambridge Core and Studies on The Lichen Genus Sticta (Schreber) Ach.: I. Southern South American Species | The Lichenologist | Cambridge Core are DOIs for the same article.

Using the https://hdl.handle.net resolver, both point to the same URL, so it’s not even that one DOI redirects to the other, they both point to exactly the same thing.

https://0-www-cambridge-org.libus.csd.mu.edu/core/product/identifier/S0024282994000344/type/journal_article

4

Hello @rdmpage ,

Thanks for following up on this. As you’ll remember, Amanda Bartell, our head of membership, wrote a forum post about what we’re doing about registration of duplicate DOIs.

I won’t rehash all of those details, but we continue to: 1) stress this to our members who are acquiring ownership of transferred journals and journal articles; 2) flag the registration of DOIs that have similar bibliographic metadata registered with us (with a warning at the time of registration called a conflict); and 3) proactively contact members who are still registering those duplicate DOIs.

Our colleague Dominika did recently rerun and expand the research that she began on this topic in 2020. She’s presented that internally, and several of us are meeting later this month to decide on a plan based on her findings.

Here’s what we know:

  1. We’re talking about less than one percent of all content registered with us; sure, that’s a lot of content;

  2. We all agree that we want to further reduce the registration of duplicate DOIs;

  3. We, too, have seen and are aware of these examples of “branded” duplicates. We’d like to put an end to that altogether. We’ve contacted several of those members about this and continue to work to curb the practice;

  4. We’ve also been working on cleaning up existing examples by having those members flag a single definitive DOI (we call this the primary DOI) in cases where duplicates have been registered. We’ve also seen examples of the best intentioned members mistakenly registering duplicate DOIs due to human or system error. I’ve been working with one such member on cleaning up a mistake like that for over a year.

Amanda also mentioned that we want to improve how we expose duplicate DOIs in our REST API. While it remains a high priority, we have not yet made those changes: [CR-175] - Jira.

We’ll post an update in the community forum when we have definitive next steps.

2 Likes
5

Thanks @ifarley, I realise that this can be a challenging problem.

I’ve come across yet another example, this time for the journal Amphibia-Reptilia, e.g. “Two new species of anoles of the Norops crassulus group from Honduras (Reptilia: Sauria: Polychrotidae)” Two new species of anoles of the Norops crassulus group from Honduras (Reptilia: Sauria: Polychrotidae) in: Amphibia-Reptilia Volume 20 Issue 3 (1999) and https://0-doi-org.libus.csd.mu.edu/10.1163/156853899507077. Both DOis are in CrossRef’s database with full metadata, one DOI resolves to the article [10.1163/156853899x0030], the other resolves to Brill’s web site [10.1163/156853899507077].

One thing I noticed in the CrossRef metadata is that the order of ISSNs (print and electronic) is different for the two records, and only seems to be the case for volume 20 of the journal (which has duplicate DOIs) so perhaps the problem is queries matching using ISSNs may fail if they take just the first ISSN. That is, if you take the first ISSN the records will appear to be different. If you are keeping track of reasons why duplicates occur this could o on the list.

6

HI @rdmpage ,

I’ve written our contacts at Brill about aliasing one of those two DOIs to the other, so we can improve the situation and clearly have them, Brill, signal which DOI should be the definitive DOI for the content going forward. Looks it should be DOI 10.1163/156853899X00303, but I’ll confirm once I know more. Our contact at Brill is very responsive, so hope to have an answer early next week.

As for the larger question: both of these DOIs were originally registered with us over 15 years ago (DOI 10.1163/156853899X00303 registered with us in April 2008 and DOI 10.1163/156853899507077 registered with us in July 2002), so determining why that happened can be hard to piece back together. I can definitively say that the way we flag these conflicts and registrations has changed since 2008, so we’ve had system-level changes. I suspect Brill has had changes in their system and possibly their process as well.

Today, if either ISSN is in the record, no matter the order, the record is retrievable in our APIs, so if members have a pre-check in place in their workflow to determine if a DOI or set of DOIs has previously been registered for the content in question, that check of our APIs for the ISSNs would return these DOIs. But, I can tell you that I believe only a minority of our members have a robust pre-check confirmation process in place. Some do, and we really need to illuminate those members and their processes.

Based on my experience, the most common reasons for duplicates is human error (i.e., I put those ‘branded’ duplicates here, but that’s not the only human error) and system limitations (e.g., some systems don’t easily allow for display/maintenance of DOIs on multiple prefixes).

I’ll be in touch about the specific duplicate you’ve reported.

My best,
Isaac