In my previous articles, I have talked about general problems with DOIs (http://www.russet.org.uk/blog/2011/02/the-problem-with-dois/), about architectural issues with capturing metadata (http://www.russet.org.uk/blog/2012/03/dois-and-content-negotiation/), and finally, about specific problem DOIs (http://www.russet.org.uk/blog/2012/03/a-problem-doi).
I have also described part of the difficulty is that it is hard to determine the registration agency associated with a specific DOI — there are actually different kinds of DOI and they respond in different ways.
I have, however, finally found a way to discover who is a responsible for a given DOI. One of my own papers (http://www.jbiomedsem.com/content/1/S1/S7) declares its DOI to be 10.1186/2041-1480-1-S1-S7. Unfortunately, refering to this paper using Kcite (http://www.russet.org.uk/blog/2012/02/kcite-spreads-its-wings/) shows, at the time of writing, an error message (10.1186/2041-1480-1-S1-S7), nor does the DOI resolve. As this may later be fixed, the error message looks like this:
The DOI you requested -- 10.1186/2041-1480-1-S1-S7 -- cannot be found in the Handle System. Possible reasons for the error are: the DOI has not been created the DOI is cited incorrectly in your source the DOI does not resolve due to a system problem
On filling in the “this DOI does not work” form, the error page redirects to, the another URL at http://notfound.doi.org/DoiError/servlet, which says:
The DOI and comments (if provided) have been logged by CrossRef and forwarded to the publisher to correct the problem. Possible reasons for the error are: the DOI has been created but has not been registered by the publisher (this could be an error or it could be a timing issue and the DOI will be registered in the next few days) the DOI is cited incorrectly in the source the DOI does not resolve due to a system problem Maintaining the integrity of DOIs is very important to CrossRef and we appreciate your help.
Which suggests to me clear this DOI (should have) been registered with CrossRef. Unfortunately, this only works with DOIs that do not resolve in the first place. Directly accessing the link returns “nothing to see here”.
A little bit of poking around, and I have discovered a few other problematic DOIs, all from the same “special issue”.
I might take this personally, as this includes another paper of mine, although, strangely, two of the DOIs from the same issue do work which also includes one of mine.
All of this demonstrates an advantage of our Kcite tool (http://knowledgeblog.org/kcite-plugin). By actually using primary identifers as part of the authoring process, I have discovered five DOIs, several of which have been on my website for a long time, that are broken. Possibly, the Journal of Biomedical Semantics should take a leaf out of my book. From their web page:
Journal of Biomedical Semantics 2010, 1(Suppl 1):S7 doi:10.1186/2041-1480-1-S1-S7 The electronic version of this article is the complete one and can be found online at: http://www.jbiomedsem.com/content/1/S1/S7
At the time of writing, the DOI is not displayed as http://dx.doi.org/10.1186/2041-1480-1-S1-S7, although this is a hard requirement from CrossRefs display guidelines (http://www.crossref.org/02publishers/doi_display_guidelines.html). Ironically, CrossRef says “CrossRef DOIs should always be displayed as permanent URLs in the online environment.” This seems to miss the requirement that, in the online environment, DOIs should be hyperlinked, so the Journal of Biomedical Semantics cannot be faulted there. It is a shame, though. If they were hyperlinked by now a web crawler would have discovered the 404.
Since I wrote this post, three out of four of the errorneous DOIs that I reported have been fixed. One of them (http://dx.doi.org/10.1186/2041-1480-1-S1-S2) is still broken. As I am using kcite to refer to these DOIs, the references have now automatically updated.