This is a follow-on to an earlier post which set out the lie of the land as regards DOI services and data for DOIs registered with Crossref. That post differentiated between a native DOI resolution through a public DOI service which acts upon the “associated values held in the DOI resolution record” (per ISO CD 26324) and other related DOI protected and/or private services which merely use the DOI as a key into non-public database offering.
Following the service architecture outlined in that post, options for exposing public data appear as follows:
Private Service
-
Publisher hosted – Publisher private service
-
Protected Service
-
Crossref hosted – Industry protected service
-
Crossref routed – Publisher private service
-
Public Service
-
Handle System (DOI handle) – Global public service (native DOI service)
-
Handle System (DOI ‘buddy’ handle) – Publisher public service
(Continues below.)
<p>
With Library of Congress sometime back (Feb. ’08) announcing LCCN Permalinks and NLM also (Mar. ’08) introducing simplified web links with its PubMed identifier one might be forgiven for wondering what is the essential difference between a DOI name and these (and other) seemingly like-minded identifiers from a purely web point of view. Both these identifiers can be accessed through very simple URL structures:
With Library of Congress sometime back (Feb. ’08) announcing LCCN Permalinks and NLM also (Mar. ’08) introducing simplified web links with its PubMed identifier one might be forgiven for wondering what is the essential difference between a DOI name and these (and other) seemingly like-minded identifiers from a purely web point of view. Both these identifiers can be accessed through very simple URL structures:
http://lccn.loc.gov/2003556443
And the DOI itself can be resolved using an equally simple URL structure:
So, why does DOI not just present itself as a simple database number which is accessed through a simple web link and have done with it, e.g. a page for the object named by the DOI “10.1000/1” is retrieved from the DOI proxy server at http://dx.doi.org/?
Essentially the typical DOI link presents an elementary web-based URL which performs a useful redirect service. What is different about this and, say a PURL, which offers a similar redirect service? What’s the big deal?
(Continues below.)
I was invited to speak at the Handle System Workshop which was run back to back with an IDF Open Meeting earlier this week in Brussels and hosted at the Office for Official Publications of the European Union. (Location was in the Charlemagne Building, at left in image, within the rather impressive meeting room Jean Durieux, at right.)
My talk (‘A Distributed Metadata Architecture‘) was focussed on how OpenHandle and XMP could be leveraged to manage dispersed media assets.
A Crossref Member Briefing is available that explains how PubMed Central (PMC) links to publisher full text, how PMC uses DOIs and how PMC should be using DOIs. The briefing is entitled “Linking to Publisher Full Text from PubMed Central” (PDF 85k).
Crossref considers it very important the PMC uses DOIs as the main means to link to the publisher version of record for an article and we are recommending that publishers try to convince PMC to use DOIs in an automated way.
Interesting post from Yahoo! Search’s Director of Product Management, Priyank Garg, “One Standard Fits All: Robots Exclusion Protocol for Yahoo!, Google and Microsoft“. Interesting also for what it doesn’t talk about. No mention here of ACAP.
As the range of public services (e.g. RSS) offered by publishers has matured this gives rise to the question: How can they expose their public data so that a user may discover them? Especially, with DOI there is now in place a persistence link infrastructure for accessing primary content. How can publishers leverage that infrastructure to advantage?
Anyway, I offer this figure as to how I see the current lie of the land as regards DOI services and data.
(Click to enlarge.)
For infotainment only (and because it’s a pretty printing). Glimpse into the dark world of DOI. Here, the handle contents for doi:10.1038/nature06930 exposed as a standard OpenHandle ‘Hello World’ document. Browser image courtesy of Processing.js and Firefox 3 RC1.
So, why is it just so difficult to reference OpenURL?
Apart from the standard itself (hardly intended for human consumption - see abstract page here and PDF and don’t even think to look at those links - they weren’t meant to be cited!), seems that the best reference is to the Wikipedia page. There is the OpenURL Registry page at http://openurl.info/regsitry but this is just a workshop. Not much there beyond the OpenURL registered items.
So, the big guns have decided that XRI is out. In a message from the TAG yesterday, variously noted as being “categorical” (Andy Powell, eFoundations) and a “proclamation” (Edd Dumbill, XML.com), the co-chairs (Tim Berners-Lee and Stuart Williams) had this to say:
“We are not satisfied that XRIs provide functionality not readily available from http: URIs. Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications.
Following on from yesterday’s post about making metadata available on our Web pages, I wanted to ask here about “metadata reuse policies”. Does anybody have a clue as to what might constitute a best practice in this area? I’m specifically interested in license terms, rather than how those terms would be encoded or carried. Increasingly we are finding more channels to distribute metadata (RSS, HTML, OAI-PMH, etc.) but don’t yet have any clear statement for our customers as to how they might reuse that data.
