Ticket of the month - July 2022 - Retrieving metadata records for aliased DOIs

Hello all,

I thought this month I’d address a question that we get from time to time into support@crossref.org. The question deals with retrieving metadata records for DOIs that have been aliased to other DOIs. You can learn more about aliased DOIs in the conflict report section of our documentation. But, for this post, this is what you need to know about aliased DOIs:

Aliasing DOIs become necessary when you have assigned two DOIs to the same content item. In these cases of duplicate DOIs (we call this general situation where matching metadata has been registered for two or more DOIs a conflict), you can resolve that conflict by assigning one of the DOIs as primary and the other as its alias. The aliased DOI will automatically redirect to the primary DOI, so you’ll only need to maintain the primary. This effectively hides the aliased DOI and means it will not be cited.

Now, because the two (or, more) DOIs were out in the world, we do get questions about retrieving metadata records for those aliased DOIs - the DOIs that the member responsible for the content has determined will not be maintained.

Those questions are sometimes as simple as this:

When I search for https://0-api-crossref-org.library.alliant.edu/works/10.5479/si.0081024x.43 , the REST API returns the resource not found message below. Why is that? I can see that this DOI has been registered before: https://doi.org/10.5479/si.0081024x.43

It’s a good question. That DOI is not in the REST API because it has been aliased to DOI 10.5479/si.0081024X.43.1 and we’re actively trying to hide the DOI and its metadata record in favor of the primary DOI. You can see this more clearly in our XML API: http://0-doi-crossref-org.library.alliant.edu/search/doi?pid=support@crossref.org&format=unixsd&doi=10.5479%2Fsi.0081024x.43

This element near the top of the record tells me the DOI has been aliased to the 10.5479/si.0081024X.43.1 prime (or, primary DOI):

<crm-item name="prime-doi" type="string">10.5479/si.0081024X.43.1</crm-item> 

Clearly we’re inconsistent in how we return aliased DOIs across our APIs. We’re working on improving how we handle aliased DOIs in the REST API. You may monitor our progress here: https://crossref.atlassian.net/browse/CR-175.

For now, a check in the XML API will confirm if a DOI has been aliased (or, in seeing the link between a primary DOI and its alias).

Thanks for reading,