Blog

I blogged here back in Jan. 2007 about Adobe submitting PDF 1.7 for standardization by ISO. From yesterday’s ISO press release this: “The new standard, ISO 32000-1, Document management – Portable document format – Part 1: PDF 1.7, is based on the PDF version 1.7 developed by Adobe. This International Standard supplies the essential information needed by developers of software that create PDF files (conforming writers), software that reads existing PDF files and interprets their contents for display and interaction (conforming readers), and PDF products that read and/or write PDF files for a variety of other purposes (conforming products).

For anybody interested in the why’s and wherefore’s of OpenURL, Jeff Young at OCLC has started posting over on his blog Q6: 6 Questions - A simpler way to understand OpenURL 1.0: Who, What, Where, When, Why, and How (note: no longer available online). He’s already amassing quite a collection of thought provoking posts. His latest is The Potential of OpenURL (note: no longer available online), from which: OpenURL has effectively cornered the niche market where Referrers need to be decoupled from Resolvers.

This test form shows handle value data being processed by JavaScript in the browser using an OpenHandle service. This is different from the handle proxy server which processes the handle data on the server - the data here is processed by the client. Enter a handle and the standard OpenHandle “Hello World” document is printed. Other processing could equally be applied to the handle values. (Note that the form may not work in web-based feed readers.

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:

1. Private Service

   1. Publisher hosted – Publisher private service
2. Protected Service
   1. Crossref hosted – Industry protected service
   2. Crossref routed – Publisher private service
3. Public Service
   1. Handle System (DOI handle) – Global public service (native DOI service)
   2. 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:

• https://lccn.loc.gov/2003556443

  • http://www.ncbi.nlm.nih.gov/pubmed/16481614 (although https://web.archive.org/web/20090106151604/http://pubmed.com/1386390 also works as noted here)

  And the DOI itself can be resolved using an equally simple URL structure:

  • http://dx.doi.org/10.1000/1

  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.