WDscholia
10.1002/pssb.202500316 results in DOI does not exist when valid DOI
Describe the bug 10.1002/pssb.202500316 results in DOI does not exist, but does exist when visited via link https://doi.org/10.1002/pssb.202500316
To Reproduce Steps to reproduce the behavior:
- Try to load the DOI url directly https://scholia.toolforge.org/doi/10.1002/pssb.202500316
- result: "DOI does not exist"
Expected behavior resolve DOI to Q or load quickstatement
Screenshots
Desktop (please complete the following information):
- OS: Windows
- Browser Firefox
- Version 142.0.1
This just worked for me, I've created the wikidata item.
The most likely issue is a delay in crossref indexing. There are at least four separate operations which we common assume are atomic, but are actually not:
(a) Publishers minting a DOI (so it can be included in documents). (b) Adding a target for the DOI to redirect to (c) Publishers submitting DOI metadata to for indexing (d) That publisher-submitted metadata being accessible via search.crossref.org
The "DOI does not exist" message should probably be updated to be more helpful.
The "DOI does not exist" message should probably be updated to be more helpful.
Yes!
How about "Metadata lookup for DOI failed. Check DOI for typos / cut-and-paste errors. If DOI is recently minted this may be because the publisher has not yet submitted metadata to crossref; check back in 1-4 weeks. You can check in crossref at https://search.crossref.org/DOI"
The first DOI in there should be a link to the underlying doc via the DOI. The last should be a working link to the crossref search index.
Historically crossref have been very good, but they've had some issues recently, see https://community.crossref.org/t/whats-going-on-with-the-rest-api-indexing-issues/14341
Some publishers can also be a little tardy.
Additionally, metadata submission and indexing is batched, which means that a single 'bad' item can cause an entire batch (usually one or more issues of a journal) to be blocked until the issue is resolved. This can be a issue with OJS-based journals.
10.21980/j8ph1b is another example, but this looks like it may be a data migration issue as the as the article is from 2022 and the 10.21980 was migrated from DataCite per the notes of doi.org/10.21980 state the migration 10/8/2025.