Discussion on Crossref

Knols and Citations Part II

Ed Pentz — Thu, 24 Jul 2008 00:00:00 +0000

Tony’s post highlights Knol’s “service” URIs. Another issue is that many Knol entries have nice long lists of unlinked references. The HTML code behind the references is very sparse.

Might the DOI be of use in linking out from these references? I think so. Then, of course, there’s the issue of DOIs for Knols…

The Thing About DOI

Tony Hammond — Mon, 30 Jun 2008 00:00:00 +0000

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.pluma.sjfc.edu/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.pluma.sjfc.edu/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.pluma.sjfc.edu/?

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.)

Well, the thing about DOI is that it is built upon a directory service - the Handle System - and can be accessed either through native directory calls or more likely through standard web interfaces. From a web point of view we are usually interested in the latter. Differently from a simple lookup and/or redirect service which has a fixed entry point on the Web, the DOI can be serviced at any DOI service access point on the Internet. There are potentially multiple entry points which can be hosted by different organisations with separate IP addresses and/or DNS names.

 For example, the [DOI proxy][8] (described [here][9]) is just _one instance_ of such a service. Others could equally exist. And, in fact, they do. The following handle web services will also take the DOI and do the business:
* <http://hdl.handle.net/10.1000/1>
* <http://hdl.nature.com.pluma.sjfc.edu/10.1000/1></ul>
With handle we have in essence a redirect to a redirect. Or in the case of a web service, a redirect (from HTTP to HDL) to a redirect (from HDL to HDL) to a redirect (from HDL to HTTP). That is, switch down from the web interface to the native handle layer, route the call from this local handle sever (via the global handle server) to the DOI handle server, fetch the URL stored with the DOI and switch back to the Web at that location.
But there’s more. The standard URL redirect is just _one_ example of a DOI service. But multiple services can also be provided for the DOI. Currently the DOI travels light and is bound to the minimum of useful data, essentially just the URL for a splash page in the case of many Crossref DOIs. But it could also carry pointers to structured information or to relationships with other objects.
As yet, the DOI is a fledgling in terms of realizing its true potential as a seasoned actor that can play out many roles - assume many guises. A queen bee, in effect, with a hive of worker bees servicing it. It is not joined at the hip with any particular web service as might be commonly understood with the current simple redirect service. It offers much more.
It is, however, true that both for reasons of link persistency and in order to maintain link ranking with search crawlers that a preferred web entry point is via the [DOI proxy][8]. It just doesn’t have to be that way - that’s all. Hard linking is something we are beginning to unlearn and instead we are taking our first steps towards embracing service-mediated links such as OpenURL and DOI can both offer.

Exposing Public Data

Tony Hammond — Sat, 31 May 2008 00:00:00 +0000

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.

Legend - Current DOI service architecture showing data repositories, service access points, and open/closed data domains.

The figure above shows the three data repositories and service access points in the current DOI services architecture. At right and bottom of the figure are the two types of service (public services and private services) that together are instrumental in getting a user from a DOI-based link (on a third-party site) to the correct page of content (from the primary content provider). (Note that a fourth, private data repository – the institutional repository – comes into play when OpenURL user context-sensitive linking is added.)

At left of the figure are services operated by Crossref on its own metadata database which support a) publisher lookups of DOI, and b) third-party metadata services (DOI-to-metadata and metadata-to-DOI conversions). These might best be labelled protected services since they are not freely available: the first is open to members at a cost, while the second is free but to associated organisations only – members, affiliates, etc.

The term open data is used here in the sense implied by the current W3C SWEO LOD (Linking Open Data) Project. Open data is public data unencumbered by any access restrictions. By contrast, closed data is data that has some access restrictions placed on it – even data that is open to affiliates. (This is not an issue that LOD addresses directly, although it is implied that data is globally ‘open’, i.e. public.)

The current DOI service architecture thus breaks down as:

Native DOI services – resolving the DOI token
- Public – DOI Proxy Server (‘dx.doi.org’)
- Related DOI services – using the DOI token
  - Protected – Crossref
    - Private – Publisher
  Note that a DOI is ‘resolved’ into state data registered with it, or as ISO CD 26324 puts it: “Resolution is the process of submitting a specific DOI name to the DOI system and receiving in return the associated values held in the DOI resolution record for one or more types of data relating to the object identified by that DOI name.”
  
  So, how might publishers best leverage this DOI service architecture to expose their public data?

Referencing OpenURL

Tony Hammond — Thu, 29 May 2008 00:00:00 +0000

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://alcme.oclc.org.pluma.sjfc.edu/openurl/servlet/OAIHandler?verb=ListSets but this is just a workshop. Not much there beyond the OpenURL registered items. (And why does the page seem uncertain as to whether it’s a “repository” or a “registry”? Is there no difference between those terms?) The only other links are to a mix of HTML and PDF resources. (There really should be a health warning on links to PDFs - they are just not browser friendly documents.) And, I do have to wonder at this: the registry page has a link to the unofficial 0.1 version but not to the 1.0 standard. Er, why? And don’t even try this link: http://openurl.info/. Not much info there.

Where else to go? The NISO site allows a search on “openurl” which returns links to the standard and to other related documents.

And then there’s the community site https://web.archive.org/web/20091027024029/http://openurl.code4lib.org/ targeted at developers and its Planet OpenURL which is a useful source for current awareness.

Me, I’m sticking with the Wikipedia page as the best reference for OpenURL. How odd that OpenURL aimed at improving linking on the Web should not have it’s own simple access point. Thank heavens at least that DOI has a single reference point: http://doi.org.pluma.sjfc.edu/.

Chapter 9 - The Closed Book

Tony Hammond — Sat, 15 Sep 2007 00:00:00 +0000

Hadn’t really noticed before but was fairly gobsmacked by this notice I just saw on the DOI® Handbook:

**Please note that Chapter 9, Operating Procedures is for Registration Agency personnel only.**

DOI® Handbook

doi:10.1000/182

http://www.doi.org.pluma.sjfc.edu/hb.html

And, indeed, the Handbook’s TOC only reconfirms this:

9 Operating procedures*

*The RA password is required for viewing Chapter 9.

9.1 Registering a DOI name with associated metadata

9.2 Prefix assignment

9.3 Transferring DOI names from one Registrant to another

9.4 Handle System® policies and procedures

9.4.1 Overview

9.4.2 Policies and Procedures

9.4.3 Requirements for Administrators of Resolution Services

9.4.4 Protocols and Interfaces

9.5 DOI® System error messages

That’s spooky. A book with a hidden chapter. I really don’t like that at all. Especially on a book aiming to provide general information and guidance. Seems to be that if that information needs to be kept private to RA’s then it has no business rubbing shoulders with public information. I would suggest that the material be opened up or else moved out. Makes me feel so second class.

CrossTech

Tony Hammond — Mon, 02 Oct 2006 00:00:00 +0000

<span >Just a couple comments about CrossTech:

<span >1. Shouldn’t it (or couldn’t it) be linked to from the Crossref home page? (This is a public read list after all and so should be made more widely available.) Maybe at some point could be announced on some lists of interest.

<span >2. Would be very nice to (at least) have a count of membership. I would also like to canvas opinions about making names of the membership public. What do others think about this?

<span >At the end of the day though this facility needs to be driven, otherwise it will end up being just another pier over the water (i.e. a ‘disappointed bridge’ And sorry for cribbing again from JAJ).

Embedding standardized metadata in HTML

Ed Pentz — Tue, 05 Sep 2006 00:00:00 +0000

On the iSpecies blog Rod Page describes how he extracts DOIs from Google Scholar results - he does use the Crossref OpenURL interface and Connotea to get DOIs too. He also says “DOIs are pretty cool” which is good!

On another blog post to SemAnt Page describes how he uses LSIDs and DOIs for Ant literature.

It seems that there is more and more of this type of use of the DOI so its great we have the OpenURL interface. Could the type of stuff that Page is doing be helped by publishers embedding metadata in their HTML pages? This could include licensing info and information for search engine crawlers.

Ingenta and BMC embed metadata (are there others?) - here is a snippet from a BMC article -

<cc:Work rdf:about="http://www.biomedcentral.com/1471-2148/3/16">
<cc:license rdf:resource="http://creativecommons.org/licenses/by/2.0/"/>
</cc:Work>
<cc:License rdf:about="http://creativecommons.org/licenses/by/2.0/">
<cc:permits rdf:resource="http://web.resource.org/cc/Reproduction"/>
<cc:permits rdf:resource="http://web.resource.org/cc/Distribution"/>
<cc:requires rdf:resource="http://web.resource.org/cc/Notice"/>
<cc:requires rdf:resource="http://web.resource.org/cc/Attribution"/>
<cc:permits rdf:resource="http://web.resource.org/cc/DerivativeWorks"/>
</cc:License>
<item rdf:about="http://www.biomedcentral.com/1471-2148/3/16">
<title>Inter-familial relationships of the shorebirds (Aves: Charadriiformes) based on nuclear DNA sequence data</title>
<dc:title>Inter-familial relationships of the shorebirds (Aves: Charadriiformes) based on nuclear DNA sequence data</dc:title>
<dc:creator>Ericson, Per GP</dc:creator>
<dc:creator>Envall, Ida</dc:creator>
<dc:creator>Irestedt, Martin</dc:creator>
<dc:creator>Norman, Janette A</dc:creator>
<dc:identifier>info:doi/10.1186/1471-2148-3-16</dc:identifier>
<dc:identifier>info:pmid/12875664</dc:identifier>
<dc:source>BMC Evolutionary Biology 2003, 3:16</dc:source>
<dc:date>2003-07-23</dc:date>
<prism:publicationName>BMC Evolutionary Biology</prism:publicationName>
<prism:publicationDate>2003-07-23</prism:publicationDate>
<prism:volume>3</prism:volume>
<prism:number>1</prism:number>
<prism:section>Research article</prism:section>
<prism:startingPage>16</prism:startingPage>
</item>
</rdf:RDF>

SEMANTIC WEB: GOOGLE HAS THE ANSWERS, BUT NOT THE QUESTIONS

Ed Pentz — Tue, 22 Aug 2006 00:00:00 +0000

Posted by special permission from EPS

EPS INSIGHTS :: 01/08/2006

SEMANTIC WEB: GOOGLE HAS THE ANSWERS, BUT NOT THE QUESTIONS

The Google v. Semantic Web discussion at the AAAI (American Association for Artificial Intelligence) featured plenty of confrontation and even some rational argument, but it may chiefly be remembered as the day when Google responded to the challenge of semantic web thinking by saying that the semantic web movement did not matter - thereby demonstrating that it did.

by David Worlock, Chairman

And we thought that the real battle this year was between net neutrality and the network owners. Or between those who think that click fraud crucially undermines Google, and those who think it doesn’t matter. We were wrong. July’s “Thrilla in Manila” was the discussion between Tim Berners-Lee and the Google Director of Search, Peter Norvig, at the Boston AAAI meeting. And it is an important moment because Berners-Lee’s assertion that the last semantic web building blocks are moving into place comes at exactly the time when Google seems anxious to diminish semantic web searching. It is a good guess that the latter results from a stimulus dictated by threat. A world where keyword searching was reduced to ground floor in a building of many storeys where it may even be an advantage to be a new market entrant with no history is a world where Google would have to progressively re-invent itself. And what is more difficult, in the recent history of these things, than a company created by a technology re-inventing itself in terms of a new technology?

So Google’s Boston blows were first of all aimed at the reality test. Like STM publishers pointing to the unlikelihood of academic researchers adding metadata to articles for repository filing, Google pointed to user and webmaster incompetence as the chief reason why semantic interoperability was doomed to a long, slow and painful generative process. If users cannot configure a server or write HTML, how can they understand all this stuff? And then suppliers would slow it down by trying to make it proprietary. And then, machine to machine interoperability would encourage deception (obviously the click fraud business is hurting). The answer to the Semantic Web, from a Google stance, thus appears to be: very interesting, but not very soon.

Dancing like a bee and stinging like a butterfly, Tim Berners-Lee clearly had the answers to this. The reason why the semantic web appears threatening to those who have entrenched tenancies in search is probably because it is going quicker than expected. His original ‘layer cake’ diagram, a feature on the conference circuit for five years, could now be completed at all levels. RDF as a data language is now well-established (think of RSS). Ontologies, mostly in narrow vertical domains, are moving into place, though there may be issues about relating them to each other. Query and rules languages now populate the other layers, with one of the former, SPARQL, emerging this year as a W3C candidate recommendation (6 April 2006). In a real sense this is the missing link which makes the Semantic Web a viable proposition, and at the same time joins it to the popular hubbub around Web 2.0. If part of the latter dream is data sourcing from a wide variety of service entities to create new web environments from composite content, then SPARQL sitting on top of RDF looks closest to realising that idea. In an important note in O’Reilly XML.com (SPARQL: Web 2.0 Meet the Semantic Web; 16 September 2005), Kendall Clark wrote “Imagine having one query language, and one client, that lets you arbitrarily slice the data of Flickr, del.icio.us, Google, and your three other favourite Web 2.0 sites, all FOAF files, all of the RSS 1.0 feeds (and, eventually, I suspect, all Atom 1.0 feeds) plus MusicBrainz etc”.

Imagining that might well impel you into the ring with Tim Berners-Lee. If Google has to be re-invented, the process of recognition of change has to be slowed. Denying the speedy reality of the semantic web becomes essential while furious R&D takes place. And content and information service providers are not just spectators of this, but participants too.