hvdsomp

This is a very significant problem indeed. In our reference rot study (http://dx.doi.org/10.1371/journal.pone.0115253), we found that a very significant amount of papers were referenced by means of their landing page URL instead of by their DOI URL. As part of the "Signposting the Scholarly Web" work, we looked into this issue and thought that using a "canonical" link from the landing page URL to the DOI URL would be a good step.

It needs to be understood that "canonical" was really introduced in the context of search engine optimization and is supported by web search engines. In essence, if a landing page would have a "canonical" link to the DOI RL, the content of the landing page would be indexed under the DOI URL.

For browsers, the desired behavior would be to bookmark a page that has a "canonical" link under the canonical URL instead of the page's URL. At this time, to the best of my knowledge, this is not supported by browsers. However, it seems to me that it should not be impossible to achieve this, if, for example, the Persistent Identifier community (DOI, handle, PURL, ark, ...) would lobby for it. Alternatively, one could write an RFC and define another link relation type specifically for this relation type between landing page and persistent identifier. And lobby browser manufacturers to implement the "right" bookmarking behavior for it. But, the difference between "canonical" and this special-purpose relation type might be too subtle to make it through IANA registration scrutiny.

DOIs work for referencing resources because someone, e.g. a scholarly publisher, has a self-interest in making sure that DOI-based links keep working. They put a concerted effort in making that happen. When referencing "web at large" resources that reside on any kind of web server out there, the admin of that web server is typically not very interested in putting work in to keep links working. Hence, the person putting a link to a "web at large" resource in, or the platform on which such link is published, caries the burden to keep the link working. Our Robust Links work (http://robustlinks.mementoweb.org/) is all about how that can be done. As someone in this thread says, it involves "metadata". But not the kind of metadata that's mentioned in his post; it's all more webbie than that. Note that link rot is not the only problem for "web at large resources". Content drift is another: content at the end of a link changes. See also my comment in the Mozilla Science discussion "What makes code a research object" (https://github.com/mozillascience/code-research-object/issue...). And see our extensive study regarding reference rot in scholarly communication (http://dx.doi.org/10.1371/journal.pone.0115253).