2008 on Crossref

And the DOI is …

Tony Hammond — Mon, 22 Dec 2008 00:00:00 +0000

Once structured metadata is added to a file then retrieving a given metadata element is usually a doddle. For example, for PDFs with embedded XMP one can use Phil Harvey’s excellent Exiftool utility.

Exiftool is a Perl library and application which I’ve blogged about here earlier which is available as a ‘.zip‘ file for Windows (no Perl required) or ‘.dmg‘ for MacOS. Note that Phil maintains this actively and has done so over the last five years. (And when I say actively I mean just that. I once made the mistake of printing out the change file.)

If Perl’s not your thing, then there’s a Ruby wrapper gem (MiniExiftool) to access the Exiftool command in trouper OO fashion. Here’s an example Ruby one-liner to get the DOI from a PDF (broken here to meet column width restriction):

% ruby -rubygems -e 'require "mini_exiftool";<br />     puts MiniExiftool.new("test.pdf")["doi"]'<br /> 10.1038/nphoton.2008.200

Of course, that could also have been run against an image, audio or video file with XMP packet.

(Makes one wonder vaguely about the feasibility of having a Swiss Army knife type of utility that could read any file to get the DOI using the embedded XMP, RDFa, RDF, HTML headers, COiNS, etc. Possibly even as last resort fall back to scanning the raw text - if any.)

Xmas XMP

Tony Hammond — Fri, 19 Dec 2008 00:00:00 +0000

Well, as I blogged on our web publishing blog Nascent we just went live with XMP labelling on Nature in yesterday’s double issue. We will be adding XMP to all new issues of Nature as well as rolling out across all our other titles in the next few weeks and months.

The screenshots below from Acrobat (File > Properties, CMD-D / CTL-D) show what the user might see both with (bottom-left) and without (top-right) semantic markup.

As to the actual contents of the metadata record, see this sample I posted to the semantic web list.

ORE/POWDER: Remarks on Ratings

Tony Hammond — Sat, 06 Dec 2008 00:00:00 +0000

I wanted to make some remarks about the “Ease of use” and “Learn curve” ratings which I gave in the ORE/POWDER comparison table that I blogged about here the other day. It may seem that I came out a little harsh on ORE and a little easy on POWDER. I just wanted to rationalize the justification for calling it that way. (By the way, the revised comparison table includes a qualification to those ratings.)

My primary interest was from the perspective of a data provider rather than a data consumer. What does it take to get a resource description document (“resource map”, “description resource” or “sitemap”) ready for publication?

(Continues)

To look at POWDER first, it defines two sets of semantics: an “operational semantics” which is embodied in the simple XML that is intended as the primary publication vehicle, and a “formal semantics” embodied in the RDF/OWL document that would typically be generated by a POWDER processor.

The operational semantics (XML) document requires minimal RDF understanding (and arguably none at all): it only requires that URI resources be organized into groups by pattern matching, and that metadata be attached to those groups using groups.

URI patterns are specified using any of the following XML elements for inclusive patterns:

> **<includeschemes>**, **<includehosts>**, **<includeexactpaths>**, **<includepathcontains>**, **<includepathstartswith>**, **<includepathendswith>**, **<includeports>**, **<includequerycontains>**, **<includeiripattern>**, **<includeregex>**, **<includeresources>**

and their exclusive counterparts

**<excludeschemes>**, …

These are turned into corresponding regular expressions by a POWDER processor which then emits RDF/OWL classes using those expressions as property restrictions on set membership. But a publisher is not required to understand this transformation nor the formal semantics generated from the simple XML document that was authored.

Now, as to metadata. Resource group descriptors are either free text (tags) or properties from a published namespace. For example, the property name from a namespace ex: would be added in one of two ways, depending on whether it were a simple literal string (“value”, say) or a resource URI:

http://example.org/value

<ex:name rdf:resource=”http://example.org/value“/>

While technically this is RDF/XML it hardly qualifies, I think, as requiring any great knowledge of RDF, more a knowledge of XML namespaces alone would be sufficient.

And that’s about it – all that is required for publication of a POWDER “description resource” document. (The guidelines for discovery mechanisms of a POWDER document might also need to be consulted.)

So, on that basis I would judge POWDER to be at most “medium” on the “Learn curve”. However, as soon as the mapping to the formal semantics (POWDER-S) using RDF/OWL is considered, then that learn curve rating would automatically swing to “high”.

Now, ORE on the other hand is a straightforward RDF application. What does make ORE a bit of a challenge are the following two aspects:

 1. concept of named aggregation
* abstract data model - no fixed bindings</ol>
Well, the first aspect is what ORE is all about &ndash; its USP &ndash; and what it gives us beyond the simpler POWDER approach of merely describing resource bundles. Still, it’s a concept that needs to be grokked. All too easy to take it for granted.
It is the second aspect that may make ORE appear to be &#8220;difficult&#8221;. It does not prescribe a single binding or set of bindings but provides an abstract data model. That means that a prospective user must endeavour to understand something of the model before deploying.
But enough of that. Because who really reads instruction manuals anyway? So to deploy there are user guides available for one standalone document format (RDF/XML), and two carrier document formats (Atom, RDFa). That means right there that the publisher must either embrace RDF/XML or learn how to weave it into an existing document markup. (By the way, it should be remarked that there is an excellent [primer][3] available - as there is also for POWDER - and user guides for each of the formats.)
So that I think warrants the &#8220;high&#8221; rating for ORE on the learn curve, and the corresponding &#8220;low&#8221; ease of use. But that is not to say that the two initiatives are in any competition and that one should be favoured over the other. They serve different purposes. Any yet they may also have compatibilities as the previous [mapping of ORE in POWDER][4] attempts to show. I’ll leave that task for other commentators.

Resource Maps Encoded in POWDER

Tony Hammond — Fri, 05 Dec 2008 00:00:00 +0000

Following right on from yesterday’s post on ORE and POWDER, I’ve attempted to map the worked examples in the ORE User Guide for RDF/XML (specifically Sect. 3) to POWDER to show that POWDER can be used to model ORE, see

Resource Maps Encoded in POWDER

(A full explanation for each example is given in the RDF/XML Guide, Sect. 3 which should be consulted.)

This could just all be sheer doolally or might possibly turn out to have a modicum of instructional value – I don’t know. (It would be real good to get some feedback here.) There are, however, a couple points to note in mapping ORE to POWDER:

The POWDER form is actually more long-winded because it splits the RDF triples into subject and predicate/object divisions, with the first listed within an iriset and the second within a descriptorset. The net effect, however, may be somewhat cleaner since POWDER uses a simple XML format rather than RDF/XML.
- POWDER only supports simple object types (literals or resources) so the blank nodes in the RDF/XML examples for dcterms:creator cannot be mapped as such. I have chosen here to use either foaf:name or foaf:page value.
  - Likewise, and as far as I am aware, POWDER does not support datatyping but I could be wrong on this. I have thus dropped the datatypes on dcterms:created and dcterms:modified.

This is a fairly naïve mapping. POWDER’s real strength comes in defining groups of resources with its powerful pattern matching capabilities, whereas here I am using a named single resource in each iriset through the includeresource element. I think, though, this does show how the abstract ORE data model can be serialized in yet another format.

Describing Resource Sets: ORE vs POWDER

Tony Hammond — Thu, 04 Dec 2008 00:00:00 +0000

I’ve been reading up on POWDER recently (the W3C Protocol for Web Description Resources) which is currently in last call status (with comments due in tomorrow). This is an effort to describe groups of Web resources and as such has clear similarities to the Open Archives Initiative ORE data model, which has been blogged about here before.

In an attempt to better understand the similarities (and differences) between the two data models, I’ve put up the table which directly compares the two heavyweight contendors OAI-ORE and POWDER and also (unfairly) places them alongside the featherweight Sitemaps Protocol for reference.

This is very much a draft document and I will aim to update the table based on my own further reading and on any feedback that I may get (contributions gratefully received). I’m all too aware that my understanding of the respective data models is painfully limited and I, for one, hope to profit through this exercise. There will be certainly errors which I will aim to fix as soon as I get wind of them. 🙂

By the way, the ORE work especially is of interest to Crossref members and has obvious synergies with the multiple resolution potential that DOI has long promised but not quite delivered on.

CURIEs - A Cure for URIs

Tony Hammond — Wed, 03 Dec 2008 00:00:00 +0000

A quick straw poll of a few folks at London Online yesterday revealed that they had not heard of CURIE’s. And there was I thinking that most everybody must have heard of them by now. 🙂 So anyway here’s something brief by way of explanation.

CURIE stands for Compact URI and does the signal job or rendering long and difficult to read URI strings into something more manageable. (URIs do have the particular gift of being “human transcribable” but in practice their length and the actual characters used in the URI strings tend to muddy things for the reader.) So given that the Web is built upon a bedrock of URIs, anything that then makes URIs easier to handle is going to be an important contributor to our overall ease of interaction with the Web.

(Continues)

Ten years back (in February 1998) when XML was first introduced it presented a flat naming system for document markup. For purposes of modularity and markup reuse the XML Namespaces specification released the following year allowed for element and attribute names to be replaced by expanded names in which the hitherto simple names would be replaced by name pairs consisting of a namespace name and a local name. The use of URIs for the namespace name thus opened the doors to assigning globally unique names for XML element/attribute names. As a practical point (both to keep the names short and to deal with URI characters), the notion of a qualified name (or QName) was introduced, whereby the local name would be qualified by a prefix which stood in for the namespace name.

This was such a successful device that over time it was applied to URIs in general as a mechanism for abbreviation. Especially in RDF/XML schema elements were referenced by QName. And the practice has spilled over into non-XML syntaxes (e.g. the N3 and Turtle RDF grammars which use a “@prefix” directive). But there were problems since the device was grounded in XML the local names were constrained by allowable characters for XML elements and attributes (e.g. names cannot start with a digit character), as well as there being no specification for applying this same device to non-XML grammars.

CURIE is an initiative to generalize this notion of qualified names for URIs beyond the immediate XML context for naming elements and attributes (which would also allow their use in attribute values), to a more general use in applications beyond XML. The development of CURIE is based upon work done in the definition of XHTML2, and upon work done by the RDF-in-HTML Task Force, a joint task force of the Semantic Web Best Practices and Deployment Working Group and XHTML 2 Working Group. The Editor’s draft CURIE Syntax 1.0 is currently a W3C Candidate Recommendation which is receiving comments through Jan 15, 2009, at which time it is intended to put it forward as a W3C Proposed Recommendation. Meantime, though, the new W3C Recommendation RDFa Syntax in XHTML (published Oct 14, 2008) has a normative section on CURIEs (see Sect. 7).

So, what do CURIEs look like? Taking a simple RDFa example for DOI we might have a fragment such as:

<div xmlns:doi="https://doi-org.pluma.sjfc.edu/" xmlns:dcterms="http://purl.org/dc/terms/">
  <div about="doi:10.1038/nature07184">
    <span property="dcterms:hasPart" resource="[doi:10.1038/nature07184]"/>
  </div>
</div>

This would be processed by an RDFa processor to yield the RDF triple (in N3/Turtle):

<doi:10.1038/nature07184> dcterms:hasPart <https://doi-org.pluma.sjfc.edu/10.1038/nature07184> .

This triple (or fact) says that the resource identified by DOI 10.1038/nature07184 has as a component part (cf. DCTERMS vocabulary) the resource identified by https://doi-org.pluma.sjfc.edu/10.1038/nature07184. (The abstract work identified by the DOI has as a component part the splash page identified by the proxy URL.)

OK, so what’s going on? The “property” attribute takes a CURIE as value where the prefix “dcterms” is standing in for the XML namespace URI. The “about” and “resource” attributes both take a URI or CURIE as value, but because of any potential confusion a (so-called) “Safe CURIE” must be used which is a CURIE wrapped in brackets. The above example does not use brackets for the “about” attribute and therefore an RDFa processor would read this as being a full URI, i.e. &lt’doi:10.1038/nature07184>, whereas it does use brackets for the “resource” attribute and therefore this would be read as being a (Safe) CURIE, i.e. https://doi-org.pluma.sjfc.edu/10.1038/nature07184.

We can turn this around as follows:

<div xmlns:doi="https://doi-org.pluma.sjfc.edu/" xmlns:dcterms="http://purl.org/dc/terms/">
  <div about="[doi:10.1038/nature07184]">
    <span property="dcterms:isPartOf" resource="doi:10.1038/nature07184"/>
  </div>
</div>

This would be processed by an RDFa processor to yield the RDF triple (in N3/Turtle):

<https://doi-org.pluma.sjfc.edu/10.1038/nature07184> dcterms:isPartOf <doi:10.1038/nature07184> .

This triple (or fact) says that the resource identified by https://doi-org.pluma.sjfc.edu/10.1038/nature07184 is a component part (cf. DCTERMS vocabulary) of the resource identified by DOI 10.1038/nature07184. (The splash page identified by the proxy URL is a component part of the abstract work identified by the DOI.)

So what do CURIEs give us? Nothing more than a generic means to be able to make human-friendly statements such as

<doi:10.1038/nature07184> dcterms:hasPart doi:10.1038/nature07184 .

instead of having to spell it out in full triples form using long-winded URIs:

<doi:10.1038/nature07184>
  <http://http://purl.org/dc/terms/hasPart>
    <https://doi-org.pluma.sjfc.edu/10.1038/nature07184> .

Ubiquity commands for Crossref services

Geoffrey Bilder — Wed, 03 Dec 2008 00:00:00 +0000

So the other day Noel O’Boyle made me feel guilty when he pinged me and asked about the possibility using one of the Crossref APIs for creating a Ubiquity extension. You see, I had played with the idea myself and had not gotten around to doing much about it. This seemed inexcusable- particularly given how easy it is to build such extensions using the API we developed for the WordPress and Moveable Type plugins that we announced earlier in the year. So I dug up my half-finished code, cleaned it up a bit and have posted the results.

Note that the back-end that supports the plugins has been moved to more stable machines and the index is now being automatically updated with journal and conference proceeding deposits (sorry, no books yet).

Also note that we are hoping that others will look at the code for the WordPress, Moveable Type and Ubiquity plugins and create more such extensions. If you do, please let us know about them at citation-plugin@crossref.org.

RSS Good Practice Guidelines

Tony Hammond — Mon, 24 Nov 2008 00:00:00 +0000

I just wanted to flag up here Lisa Rogers’ recent review article on RSS in FUMSI (the online magazine for information professionals published by Free Pint Ltd)

RSS and Scholarly Journal Tables of Contents: the ticTOCs Project, and Good Practice Guidelines for Publishers

Especially of interest is the diagram in Fig. 2 which breaks out the metadata elements that might be encountered in a rich web feed. Worthwhile pointing out that this reflects current practice and that under the item elements one would soon hope to see publishers routinely adding in prism:doi (with the bare DOI as value) and prism:url (with DOI target URL as value) from the PRISM 2.0 vocabulary published earlier this year. Publishers should also be aware of the new PRISM Usage Rights vocabulary which is expected to be published some time in the new year.

Machine Readable: Are We There Yet?

Tony Hammond — Wed, 19 Nov 2008 00:00:00 +0000

The guidelines for Crossref publishers (“DOI Name Information and Guidelines” - [PDF, 210K][1]) has this to say in “Sect. 6.3 The response page” regarding the response page for a DOI:

“A minimal response page must contain a full bibliographic citation displayed to the user. A response page without bibliographic information should never be presented to a user.”

which would seem to be all fine and dandy. But if that user is a machine (or an agent acting for a user) they’ll likely be out of luck as the metadata in the bibliographic citation is generally targeted at human users.

So here’s a quick and dirty implementation of what a machine readable page could look like using RDFa. (The demo uses Jeni Tennison’s wonderful [rdfQuery][2] plugin which I [blogged][3] about earlier.)

Clicking the DOI link below will bring up in a sub-window a bibliographic citation which might be found in a typical DOI repsonse page. If you now click the “Read Me” link you should see an alert message which presents the bibliographic metadata as a complete RDF document (in a simple N3 – or Notation3 – format). This document is assembled on the fly by rdfQuery using the RDFa markup embedded in the page.

See the “View Source” link to list the actual XHTML markup and the RDFa properties which have been added. And note also that some of the properties are partially “hidden” to the human reader, e.g. a publication date is given in year form only whereas the machine record has the date in full, and some of the properties are fully “hidden”: print and electronic ISSNs, issue number, ending page, etc.

(Continues below.)

So, what’s new about this? There are already various means of adding metadata to pages using e.g. metadata tags (see [here][4] for an earlier post on this), or COinS objects, or even RDF/XML in comment sections. All of these have their various utilities but are still just early attempts at automation. What makes this new and compelling is that RDFa allows publishers to embed machine readable metadata that can be read as a complete machine description in RDF using pretty much off-the-shelf tools and that this markup is embedded unobtrusively into the content in the proper context.

Note that there are some similarities here between embedding an XMP packet (which includes metadata) into an arbitrary binary object, e.g. a PDF file, and embedding RDF into a section of a web page – or perhaps “draping” the RDF over the document markup would be a better term – so that the metadata travels along with the actual content.

By the way, the RDFa can be processed to yield valid RDF (as is shown in the demo) and which can also be seen by running the web page through the [RDFa Distiller][5]. (You just need to cut and paste the link of the demo page given above into the Distiller form box.) This will produce RDF in various serializations (N3, XML, Triples) from the RDFa.

So, is there really any longer any reason not to have machine readable metadata at the end of the DOI? Are we there yet?

[1]: Crossref DOI display guidelines [2]: http://code.google.com/p/rdfquery/wiki/RdfPlugin [3]: /blog/rdfquery [4]: /blog/natures-metadata-for-web-pages [5]: http://www.w3.org/2007/08/pyRdfa/

rdfQuery

Tony Hammond — Mon, 17 Nov 2008 00:00:00 +0000

Whaddya know? I was just on the point of blogging about the real nice demo given by Jeni Tennison at last week’s SWIG UK meeting at HP Labs in Bristol of rdfQuery (an RDF plugin for jQuery - the zip file is here). And there today on her blog I see that she has a full writeup on rdfQuery, so I’ll defer to the expert. :~)

All I can really add to that is that rdfQuery is a pretty darn cool way to add and manipulate RDFa using jQuery. Does it get any better?

And now that RDFa is a W3C Rec since last month (see Primer and Syntax) it will be interesting to see how Crossref members might begin to deploy it on their pages - especially on DOI landing pages.

PRISM 2.1

Tony Hammond — Fri, 24 Oct 2008 00:00:00 +0000

Yesterday a new PRISM spec (v2.1) was released for public comment. (Comment period lasts up to Dec. 3, ’08.)

Changes are listed in pages 8 and 9 of the Introduction document. Some highlights:

New PRISM Usage Rights namespace
- Accordingly usage of prism:copyright, prism:embargoDate, and prism:expirationDate no longer recommended
  - New element prism:isbn introduced for book serials
  An updated mod_prism RSS 1.0 module is available which lists all versions of PRISM specs including the forthcoming v2.1 spec. I will see about getting this added now to a more permanent location. Current version of PRISM remains at v2.0. Versions 2.0 and 2.1 are especially of interest to users of Crossref because of their support for prism:doi and prism:url and users should consider upgrading their applications, e.g. RSS feeds.

XMP Marches On

Tony Hammond — Mon, 20 Oct 2008 00:00:00 +0000

For those who may be interested in the progress of XMP, Adobe’s Gunar Penikis has just announced ¹ two new releases of XMP SDKs: XMP Toolkit 4.4 (with support for new file formats), and FileInfo SDK (for customizing CS4 UIs). More importantly, though, may be the new edition of the XMP spec - see here, which is bumped from a modest 112 page document to a 3-parter at 199 pages.

Looks to be quite a thorough spec bar one telling particular: there is no version number and no date! The previous version was likewise unnumbered though at least dated as “September 2005”. Btw, I’m not sure of there is any archive of XMP specs being maintained by Adobe. At least, I’m not aware of any page with that information. Perhaps we can refer to our earlier call to have XMP turned over to a standards organisation to formalize a public spec.

Update Aug 2022: the announcement blog post mentioned above was previously at blogs.adobe.com/gunar/2008/10/new_xmp_sdks_released.html but is no longer live. ↩︎

Yer Basic One-Liner

Tony Hammond — Tue, 14 Oct 2008 00:00:00 +0000

Here’s your basic one-line handle client (all of it) for the browser:

OpenHandle.Util().getHandleData("10.1038/nature05826", function(data) { alert(OpenHandle.Util().helloWorld(data)); });

Can’t see how to make that much shorter (bar tossing spaces). But here’s one attempt (shorter though now it’s not strictly a one-liner):

var u = OpenHandle.Util();
u.getHandleData("10.1038/nature05826", function(_) { alert(u.helloWorld(_)); });

Here I’ve used two utility convenience methods from the OpenHandle client library:

OpenHandle.Util().getHandleData(handle, callback, [server])
OpenHandle.Util().helloWorld(JSON)

You will though need to include a couple of libraries: openhandle.js and jquery.js. (Note that the getHandleData() method supplied in the openhandle.js library uses jQuery. Feel free to overwrite that.) A complete working document can thus be implemented as:

<html>
<head>
<script type="text/javascript" src="http://jqueryjs.googlecode.com/files/jquery-1.2.6.js"></script>
<script type="text/javascript" src="http://openhandle.googlecode.com/files/openhandle-0.2.3.js"></script>
<script type="text/javascript">
jQuery().ready(function() { /* action when body content is loaded */
var u = OpenHandle.Util(); u.getHandleData("10.1038/nature05826", function(_) { alert(u.helloWorld(_)); });
});
</script>
</head>
<body>
Boo!
</body>
</html>

Let me know if this doesn’t work for you. I’ve tried to test this and seems to function OK but sure as the sun rises I ain’t no JS ninja.

Of course, we normally want to do more than just dump the values. So, given that it’s pretty straightforward to grab and to manipulate a handle’s data values over the Web, how can we put this into practice?

Let’s consider a couple of Crossref use cases.

(Disclaimer: These examples are not intended as being in any way a replacement for the existing Crossref services but merely show how those services could be implemented on the client side. These illustrations will be useful for new bespoke services accessing other data elements that may be registered with the DOI.)

Single Resolution

Here is how one could implement the regular URL redirect service from the client:

var handle = "10.1038/nature05826";
var callback = function(json) {
 var hv = new OpenHandle.Handle(json).getValuesByType(‘URL')[0];
 var url = new OpenHandle.HandleValue(hv).getData();
 // alert("Redirecting to " + url);
 window.location = url;
};
OpenHandle.Util().getHandleData(handle, callback);

The getValuesByType(‘URL')[0] call returns the first handle value of type ‘URL’. The next line just parses this value as a handle value object and gets the data field, i.e. the URL itself.

Note here that this client can show the URL that the user will be redirected to. With normal DOI resolution the resolution takes place on the proxy server (dx.doi.org) and the URL is not available to the user - until they are so redirected. In fact, the user may never get to see the URL stored in the handle value if this is the head of a redirect chain.

To recap, Crossref DOIs are not resolved by the user to URLs - rather, they invoke a service on the server which returns a content page.

Multiple Resolution

Let’s now take a look at a case of Crossref multiple resolution. This code uses the getValues() method to return all values:

var handle = "10.1130/B25510.1";
var callback = function(json) {
 var s = "";
 var hv = (new OpenHandle.Handle(json)).getValues();
 for (var i = 0; i < hv.length; i++) {
 var v = new OpenHandle.HandleValue(hv[i]);
 s += v.getType() + ": " + v.getData();
 }
 alert(s);
};
OpenHandle.Util().getHandleData(handle, callback);

which yields

700050: 200508231619480000
HS_ADMIN: [object Object]
URL.0: http://www.gsajournals.org/gsaonline/?request=get-abstract&doi=10%2E1130%2FB25510%2E1
URL.1: http://bulletin.geoscienceworld.org/cgi/doi/10.1130/B25510.1
CR-LR: <MR><LI label="GeoScienceWorld" resource="URL.1" /><LI label="Geological Society of America" resource="URL.0" />

Oops! Too much information. This includes types such as ‘700050’ and ‘HS_ADMIN’ which are used by the Crossref application, and not intended for the end user. Maybe we should just limit it to the URL types with getValuesByType('URL'):

getValuesByType(‘URL'):

var handle = "10.1130/B25510.1";
var callback = function(json) {
 var s = "";
 var hv = (new OpenHandle.Handle(json)).getValuesByType(‘URL');
 for (var i = 0; i < hv.length; i++) {
 var v = new OpenHandle.HandleValue(hv[i]);
 s += v.getType() + ": " + v.getData();
 }
 alert(s);
};
OpenHandle.Util().getHandleData(handle, callback);

which yields

URL.0: http://www.gsajournals.org/gsaonline/?request=get-abstract&doi=10%2E1130%2FB25510%2E1
URL.1: http://bulletin.geoscienceworld.org/cgi/doi/10.1130/B25510.1

_(By the way, the previous example shows the unregulated state of handle types. We have everything but the kitchen sink in this one example:

simple types, both well-known (‘URL’) and opaque (‘700050’)
- compound, or namespaced, types with various hierarchy delimiters: dot (‘URL.0’, ‘URL.1’), underscore (‘HS_ADMIN’), and hyphen (‘CR-LR’)
Well, they’re all in there now so we gotta deal with that, but generally one would probably have preferred well-known types and where namespaces are used the usual dot notation as this is a) familiar to programmers, and b) supported by the handle client library code. The underscore is used in the handle RFCs for system types so that can be viewed as a sort of inline namespacing. Seems to be no obvious excuse for hyphens though.)

Back to the example we can see that the first URL goes to a Crossref service which we can dispense with since this example is to be run client side. That leaves us with the two actual URL targets. But how to differentiate those for a user choice? That’s where that other type ‘CR-LR’ comes in which provides an XML fragment that relates label to type. There are obviously many ways to support resource labelling - this is just the method used by Crossref.

Let’s parse out the XML fragment for labels and resources and save those in an object keyed on resource:

var labels = {};
var hv_ = (new OpenHandle.Handle(json)).getValuesByType(‘CR-LR')[0];
var v = new OpenHandle.HandleValue(hv_);
var xml = v.getData();
var li = xml.match(/<li [^\>]* \/>/ig);
for (var i = 0; i < li.length; i++) {
 var a = li[i].match(/label=\"([^\"]+)\"
resource=\"([^\"]+)\"/i);
 labels[a[2]] = a[1];
}

Now we’ll also need to build a similar object for the URLs:

var urls = {};
var hv = (new OpenHandle.Handle(json)).getValuesByType(‘URL');
for (var i = 0; i < hv.length; i++) {
 var v = new OpenHandle.HandleValue(hv[i]);
 urls[v.getType()] = v.getData();
}

And now with both these objects we can build a set of labelled links as:

var s = "";
for (item in labels) {
 s += "<a href=\"" + urls[item] + "\">" + labels[item] + "</a>";
}
alert(s);

to yield

<a href="http://bulletin.geoscienceworld.org/cgi/doi/10.1130/B25510.1">GeoScienceWorld</a>
<a href="http://www.gsajournals.org/gsaonline/?request=get-abstract&doi=10%2E1130%2FB25510%2E1"gt;Geological Society of America</a>

How to build a page with those labelled links is now a simple exercise. (The actual Crossref service for doi:10.1130/B25510.1 returns a page with labelled links, logos, and metadata pulled from the Crossref database.)

Next Steps

The aim of this work has been to show that getting access to handle data values and manipulating those values in the browser can be fairly straightforward. How additional values get to be added to DOIs (or other handles) and what those values refer to is another matter, but services to access such values do not need to be centralized. User-generated services are also a possibility.

OpenHandle JavaScript API

Tony Hammond — Wed, 08 Oct 2008 00:00:00 +0000

(Click figure for PDF.)

I just posted updated versions of the OpenHandle JavaScript Client Library (v0.2.2) and Utilities (v0.2.2) to the project site. Mainly this post is just by way of saying that there’s now a “cheat sheet” for the API (see figure above, click for PDF) which will give some idea of scope. The JavaScript API attempts to reflect the Java Client Library API for Handle data structures, and has in excess of 100 methods. A change log is available.

The new API supports:

Single namespace
- Introspection
  - Unit testing, see here
  Why is this of interest to Crossref? Well, if DOIs are ever to begin take advantage of their innate Multiple Resolution capabiities there needs to be nimbler means of accessing the data items stored with a DOI. A JavaScript API would allow the data to be manipulated in the browser down by the user and so enable bespoke services. That, at least, is the idea.

Handle Clients #1, #2, #3

Tony Hammond — Wed, 01 Oct 2008 00:00:00 +0000

Three alternate clients for viewing a Handle (or DOI): #1 (sky - text), #2 (black - tuples), #3 (white - cards) - the image above is clickable. When Handle clients become JavaScript-able, one really can have it one’s own way. (The JavaScript library is here, the demo service interface here - the code for setting up a new service interface can be got from the OpenHandle project.)

Noted: As of February 2023, most of the links in this blog are not longer available.

The Last Mile

Tony Hammond — Wed, 01 Oct 2008 00:00:00 +0000

The figure above (click to enlarge) is probably self-explanatory but a few words may be in order.

With no end-to-end delivery of data from the Handle System to the user’s application (browser or reader), getting data out of the Handle System has traditionally meant using the Web (ie. HTTP) as a courier - in effect, this is the “last mile” for Handle data. Typically an upstream (Handle) client provides services to the user. The most well known of these services is the URL redirect service which underpins the Crossref reference linking service. Another hosted service is the web form which displays data stored in the Handle records in a simple HTML table for user browsing. See panel a) in the figure above.

By contrast, the OpenHandle proposal aims to move data in the Handle record in structured form (JSON or XML) over the Web for downstream processing - either in the user’s browser or on the desktop. See panel b). Advantages are that the Handle data and data structures are moved closer to the user and the services provided are capable of being better targeted and made more relevant. Data mobility as a whole is much improved. The data are accessible using standard Web description and scripting languages. One might almost say (to paraphrase the well-known Java slogan “write once, run anywhere“) that this is a case of “read once, write anywhere”.

Look Ma, No Plugins!

Tony Hammond — Mon, 22 Sep 2008 00:00:00 +0000

var f = function (OpenHandleJson) { var h = new OpenHandle(OpenHandleJson); var hv = h.getHandleValues(); for (var i = 0; i < hv.length; i++) { var v = new HandleValue(hv[i]); if (v.hasType(‘URL’)) { print(v.getData()); } else if (v.hasType(‘HS_ADMIN’)) { var a = new AdminRecord(v.getData()); print(a.getAdminPermissionString()) } } }

"And that, gentlemen, is how we do that." - Apollo 13

Following on from my earlier Client Handle Demo post, this entry is just to mention the availability of a port of (part of) the Handle client library (in Java) to JavaScript: openhandle-0.1.1.js which is being maintained on the OpenHandle site. The JavaScript module contains methods for three classes: OpenHandle, HandleValue and AdminRecord.

What does all that mean? It means that Handles and their constituent values and value fields can be accessed directly within **any Web browser (using an OpenHandle service) which allows a dynamic Handle client to be generated and presented within a user context. No plugins required. The port mirrors the class methods in the standard Java client library for Handle.

As a demo of this JavaScript module in action, see this Inspector app for a card index view of Handle (and by implication DOI) records.

Crossref is hiring an R&D software engineer

Geoffrey Bilder — Thu, 18 Sep 2008 00:00:00 +0000

Crossref is hiring an R&D software engineer to work in our Oxford office. This is a fantastic opportunity to work on wide range of projects that promise to revolutionize scholarly publishing.

Multiple Resolution

Tony Hammond — Fri, 22 Aug 2008 00:00:00 +0000

I’ve been meaning for some time to write something about DOI and so-called “Multiple Resolution”, which to be honest is the only technology feature of any real interest as concerns DOI. (DOI as a business and social compact for guaranteeing name persistence of Web resources has been an extraordinarily successful venture in the academic publishing world with more than 32m items registered and maintained over eight years of operation but that may not have required any specialized technology. More a consensus to adopt a single location service in the DOI proxy.)

Multiple resolution, though. Now, that’s something else. Seems like it should be able to offer a lot of general funkiness and yet it has not been much used up to now. And I have to wonder why.

(Continues below.)

I guess we should start out with some definitions: the DOI Handbook, the (draft) ISO standard, and Crossref:

DOI Handbook - From Sect. 3.3 Multiple resolution:

“Multiple resolution allows one entity to be resolved to multiple other entities; it can be used to embody e.g a parent-children relationship, or any other relationship. … A DOI name can be resolved to an arbitrary number of different points on the Internet: multiple URLs, other DOI names, and other data types.”
- ISO CD 26324 - I’ve blogged here before about the ISO standardization of DOI which is now available as a Committee Draft. Multiple resolution is specifically mentioned in Sects. 3.2 and 6.2 and discussed in Sect. 6.1. From Sect. 3 “Terms and definitions” we have this definition:
  
  “Multiple resolution is the simultaneous return as output of several pieces of current information related to the object, in defined data structures.”
  
  And then Section 6 “Resolution of DOI name” goes on to say this:
  
  _“DOI resolution records may include one or more URLs, where the object may be located, and other
  
  information provided about the entity to which a DOI name has been assigned, optionally including but not restricted to: names, identifiers, descriptions, types, classifications, locations, times, measurements, and relationships to other entities.”_
  - Crossref - In the help page Multiple Resolution Intro there is this:
    
    “As of May 2008 the Crossref main system will support assigning more than one URL to a single DOI, a concept known as multiple resolution (MR). “
    
    The intro goes on to talk about the two pilot forms of multiple resolution service that have been trialled: a) interim page, and b) menu pop-up. The pop-up service is no longer supported. Only the interim page is currently offered as a production service. The help page Interim Page multiple resolution overview leads off thus:
    
    “Crossref’s MR service provides an interim page solution which presents a list of link choices to the end user. Each choice represents a location at which the item may be obtained and are commonly services that are co-hosting the content under agreement with the content’s Copyright holder.”
  So, there it is. That’s DOI multiple resolution. The real important thing to note is that the official DOI position (IDF, ISO) is invitingly open while both the Crossref implementation and the description of multiple resolution itself is unduly restrictive. Multiple resolution as described by Crossref is essentially the deposition of additional URLs (pointing to copies of the same resource) for alternate routing (for geographical reasons, co-hosting arrangements, etc.) with a service presentation of alternate locations for user selection.
  
  Multiple resolution proper (as per the DOI Handbook and ISO draft) is the deposition of arbitrary data values and return of same with no particular services implied. Use cases for multiple resolution include the addition of URLs for referencing different (but related) network objects, e.g. a metadata record, or other resources such as supplementary information, datasets, etc. Deposit of arbitrary data types is not yet catered for by Crossref. There could, I would suggest, at least be some rudimentary provision for depositing vanilla type/value pairs (subject to policy constraints). (There is currently some work under way in defining handle data types but this need not be any showstopper to depositing new data types as any type management system will likely need to evolve over time.)
  
  An obvious use case for multiple resolution (to me, anyway) would be the registration of a second URL which would point not onto a copy of the resource but onto a public metadata record. (I have earlier posted here about architectures and options for exposing public data.)
  
  With more than one data value in a resolution record, the process of resolving such a record is potentially complicated. As the ISO CD says in Sect. 62f:
  
  “Resolution requests should be capable of returning all associated values of current information, individual values, or all values of one data type.”
  
  The DOI Handbook itself recognizes the problems that multiple resolution may present.
  
  “If the DOI name can point to many different possible “resolutions”, how is the choice made between different options? At its simplest, the user may be provided with a list from which to make a manual choice. However, this is not a scalable solution for an increasingly complex and automated environment. The DOI name will increasingly depend on automation of “service requests”, through which users (and, more importantly, users’ application software) can be passed seamlessly from a DOI name to the specific service that they require.”
  
  Indeed, services like OpenHandle will make it much easier to programmatically access data stored in the handle record associated with a DOI name. (I have blogged previously about the OpenHandle project and its languages support.) Note that presentation of data values to a human user may be a non-issue for mediated services.
  
  And talking of computer languages it may be amusing to ruminate briefly on their own built-in support for multiple return values. Perhaps unsurprisingly, of the dominant languages Java has no such support as this recent post addresses:
  
  “Today was one of those days when I wished Java would support multiple return values… but Java allows you to return only one value either an object or a primitive type.”
  
  By contrast, languages such as Common Lisp do have support for multiple return values. See this post for some gory details and insights. Interesting also to reflect that as in the world of computing languages where there is a decided tilt towards a mainstream family of languages based on (or derived from) C, there may be dominant protocols at large on the Internet but no single “winner takes all”.

mod_prism (Updated)

Tony Hammond — Thu, 21 Aug 2008 00:00:00 +0000

I’ve just put up for comment a revised mod_prism (0.3) of the existing mod_prism RSS 1.0 module. This is now updated to the current PRISM version (v2.0) which was released in February ’08 and reissued with Errata in July ’08. The current mod_prism draft is registered here.

The new draft charts all (five) versions of the PRISM specification (v1.0-v2.0) and maps PRISM terms to RSS 1.0 elements. Though not required as such for use of terms within an RSS 1.0 feed, an RSS 1.0 module does allow for easy housekeeping as well as providing usage guidelines and examples for how to use PRISM terms within an RSS 1.0 feed.

The main interest for Crossref members will be the opportunity to update their current RSS 1.0 feeds to include the new PRISM terms prism:doi and prism:url. I blogged earlier here about prism:doi as it first appeared. The suggestions I put forward there were subsequently incorporated into the Errata for 2.0 which were published in July and are avaliable as a zip file here.

I would be very interested in receiving any feedback. I guess I should add to the v1.2 example of an RSS item in the draft an example also of a v2.0 RSS item which makes use of both prism:doi and prism:url.

Search Web Services - New Committee Drafts

Tony Hammond — Tue, 29 Jul 2008 00:00:00 +0000

As posted here on the SRU Implementors list, the OASIS Search Web Services Technical Committee has announced the release of five Committee Drafts, informally known as:

Abstract Protocol Definition (APD)
- Binding for SRU 1.2
  - Auxiliary Binding for HTTP GET
    - CQL 1.2
      - Binding for OpenSearch

Links to specific document formats are given at the bottom of the mail. A list of the TC public documents is also available here.

The next phase of work for the TC will be the development of SRU/CQL 2.0, and the Description Language.

Does Size Matter?

Tony Hammond — Mon, 28 Jul 2008 00:00:00 +0000

Interesting post from Google, in which they say:

“Recently, even our search engineers stopped in awe about just how big the web is these days — when our systems that process links on the web to find new content hit a milestone: 1 trillion (as in 1,000,000,000,000) unique URLs on the web at once!”

Puts Crossref’s 32,639,020 unique DOIs into some kind of perspective: 0.0033%. But nonetheless that trace percentage still seems to me to be reasonably large, especially in view of it forming a persistent and curated set.

Update: Talking of Google numbers, pingdom has a post “Map of all Google data center locations” with maps of US, Europe and World locations.

Five Years

Tony Hammond — Mon, 28 Jul 2008 00:00:00 +0000

Oh wow! A rather remarkable plea here from Dan Brickley on the public-lod mailing list which calls for the registrant of the dbpedia.org DNS entry to top it up with another 5+ years worth of clocktime. Some quotes:

_“The idea of such a cool RDF namespace having only 6 months left on the DNS registration gives me the worries.”

“If you could add another 5-10 years to the DNS registration I’d sleep easier at night.”

“Let me stress I’m not suggesting that this domain is actually at risk. Just that the not-at-risk-ness isn’t readily evident from a quick look in the DNS.”

“Those in the know are probably confident this is all in hand, but as the SW gets bigger I suspect we ought to establish practices such as “vocabularies that seek global adoption should always have 5+ years on their DNS registries”.”_

Yes, and maybe those cool URIs should have kite marks, too. 😉

(Btw, for those who may not already know the maximum length of time that any DNS name may be leased out in a single registration is 10 years, see the FAQ put out by ICANN.)

So, pity the poor user of a given semantic web application who may not know what the expectancy is behind the nodes in an RDF graph of assertions. Shifting sands, indeed.

Knols and Citations

Tony Hammond — Thu, 24 Jul 2008 00:00:00 +0000

So, Google’s Knol is now live (see this announcement on Google’s Blog). There’ll be comment aplenty about the merits of this service and how it compares to other user contributed content sites. But one curious detail struck me. In terms of citeability, compare how a Knol contribution (or “knol”) may be linked to as may be a corresponding entry in Wikipedia (here I’ve chosen the subject “Eclipse”):

Knol

https://web.archive.org/web/20080730124803/http://knol.google.com/k/jay-pasachoff/eclipse/IDZ0Z-SC/wTLUGw

Wikipedia: http://en.wikipedia.org/wiki/Eclipse

The Knol link includes author name, subject, and service gunk, while the Wikipedia link includes only the subject. That makes the Wikipedia link both more readily citeable as well as being to some degree discoverable. I wonder what Google’s intentions, if any, are with respect to the citing of their pages (or “knols”) as authoritative sources of information. They don’t seem to be doing themselves many favours.

I am minded of this post on Jeff Young’s Q6 which cites this passage from the HTTP spec (see RFC 2616, Sect. 3.2):

“As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify-via name, location, or any other characteristic-a resource.”

URIs bearing these so-called “characteristics” are what I would call a service URI in contrast to a name URI (something that I will elaborate on in a separate post). For now, however, I would just note that the Knol URI looks more like a service URI and the Wikipedia URI more like a name URI. I know which URI form I would prefer to cite.

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…

CrossTech By Numbers

Tony Hammond — Mon, 21 Jul 2008 00:00:00 +0000

CrossTech is two years old (less one month) and we have now seen some 145 posts. Breaking the posts down by poster we arrive at the following chart:

Note this is not any real attempt at vainglory, more a simple excuse to play with the wonderful Google Chart API. Also, above I’ve taken the liberty of putting up an image (.png), although the chart could have been generated on the fly from this link (or tinyurl here).

What is of interest in the chart is that approximately 3/4 of the posts are by Crossref members (TH, EN, RK) and 1/4 by Crossref staff (EP, GB, AT, CK). Certainly Crossref staffers are doing their bit for this blog. There’s also way too many posts from me. It would be really interesting to see some others’ views or observations per the CrossTech logo legend (“…, collaboration, …”).

I guess the real impediment is that one needs to request an account before posting. (Certainly there’s no reason for any member to be shy about requesting an account and posting.) Note that I haven’t considered the number of commentators to the blog which is larger than the number of posters. Also a number of Crossref members are very active with their own blogs. Those blogs with a tech focus could (should?) be scooped up by a Planet style aggregator if there would be sufficient interest in maintaining a publishing technology hub.

One can only hope that the numbers will continue to grow (by direct posts or by aggregations) and that there will be a wider info share over the next couple of years.

Library APIs

Tony Hammond — Mon, 21 Jul 2008 00:00:00 +0000

Roy Tennant in a post to XML4Lib announces a new list of library APIs hosted at

https://web.archive.org/web/20080730080413/http://techessence.info/apis//

A useful rough guide for us publishers to consider as we begin cultivating the multiple access routes into our own content platforms and tending to the “alphabet soup” that taken together comprises our public interfaces.

Metadata Matters

Tony Hammond — Mon, 21 Jul 2008 00:00:00 +0000

Andy Powell has published on Slideshare this talk about metadata - see his eFoundations post for notes. It’s 130 slides long and aims

“to cover a broad sweep of history from library cataloguing, thru the Dublin Core, Web search engines, IEEE LOM, the Semantic Web, arXiv, institutional repositories and more.”

Don’t be fooled by the length though. This is a flip through and is a readily accessible overview on the importance of metadata. Slides 86-91 might be of interest here. 😉

PRISM Press Release

Tony Hammond — Wed, 09 Jul 2008 00:00:00 +0000

The PRISM metadata standards group issued a press release yesterday which covered three points:

PRISM Cookbook

The Cookbook provides “a set of practical implementation steps for a chosen set of use cases and provides insights into more sophisticated PRISM capabilities. While PRISM has 3 profiles, the cookbook only addresses the most commonly used profile #1, the well-formed XML profile. All recipes begin with a basic description of the business purpose it fulfills, followed by ingredients (typically a set of PRISM metadata fields or elements), and, closes with a step-by-step implementation method with sample XMLs and illustrative images.”

PRISM 2.0 Errata

The Errata “addresses a range of issues, from editorial to technical, that have been reported by the PRISM user community.”

PRISM 2.1: The next version of the PRISM Specification, PRISM 2.1, is slated for release in late 2008. “This release will address complex rights for multi-platform and global distribution channels.”

Now What About XMP?

Tony Hammond — Tue, 08 Jul 2008 00:00:00 +0000

With PDF now passed over to ISO as keeper of the format (as blogged here on CrossTech), Kas Thomas (on CMS Watch’s TrendWatch) blogs here that Adobe should now do the right thing by XMP and look to hand that over too in order to establish it as a truly open standard. As he says:

“Let’s cut to the chase. If Adobe wants to demonstrate its commitment to openness, it should do for XMP what it has already done for PDF: Put it in the hands of a legitimate standards body. Right now it’s open in name only. “

And this:

“Adobe is pushing the XMP standard … at Adobe’s pace and in ways that benefit Adobe. (The parallels with PDF are numerous and obvious.) There are lingering technical issues waiting to be solved, however. Issues whose solutions shouldn’t have to be dependent on Adobe’s needs only.”

He’s absolutely bang on. With XMP on the threshold of finally shining through we really could do with Adobe cutting it loose. It’s time to leave home.

ISO Standard for PDF

Tony Hammond — Thu, 03 Jul 2008 00:00:00 +0000

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

Congrats to Adobe Systems!

Q6

Tony Hammond — Thu, 03 Jul 2008 00:00:00 +0000

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.

Blog has UML diags, definitions, musings, etc. - something for everybody. Definitely worth checking out.

Client Handle Demo

Tony Hammond — Tue, 01 Jul 2008 00:00:00 +0000

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

Exposing Public Data: Options

Tony Hammond — Tue, 01 Jul 2008 00:00:00 +0000

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
1. Publisher hosted – Publisher private service
Protected Service
1. Crossref hosted – Industry protected service
2. Crossref routed – Publisher private service
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>

Option #1 would make public data available through a private service at a publisher host based on the DOI. This places certain constraints on service discovery and persistence. Autodiscovery links can be placed into Web pages, but there is no opportunity to ‘embed’ the services into the DOI itself, and hence these cannot be considered native DOI services. Without a published API (and hence some degree of commitment from the publisher) the service access points (and possibly the services, too) are fragile.
Option #2 would require Crossref to develop a service which would either a) deliver some public data on behalf of the publisher, or b) route requests through to a bespoke publisher service. Both options would require development at Crossref and an upload mechanism for the publisher to pass along data or service address. Both options would be offered as a new member service and would thus likely be subject to membership policy arrangements. One should consider that there would be some restrictions on service operation. One possible restriction might be that this would be a one-time service registration at Crossref and that any additional services would need to be added at the publisher end.
Option #3 uses the existing Handle System infrastructure and provides a public read service. There are two possibilities: a) add a record (or records) to the DOI handle, or b) add records to a DOI ‘buddy’ handle under publisher control. Both require further explanation:
Option #3a would require Crossref consent. Unless these records (handle values) were registered by Crossref there would be concerns over interoperability. That and security concerns would almost certainly require that Crossref writes the record. But this would then need to be developed as per Option #2 above. And if a mechanism were put in place it could be restrictive in practice, e.g. not allowing additional records to be inserted (as already noted in Option #2).
Option #3b requires no prior Crossref consent. It is an option available to publishers who run a handle server. This can best be viewed as deploying a platform (a DOI ‘buddy’ handle) for hosting service access points with an intention to upload into the DOI handle (effectively Option #3a) as common public services are developed. In short, a public service incubator. Meantime the platform provides for an independent deployment and multiple services can be added as required. An uplink from a so-called DOI ‘buddy’ handle to the DOI handle would be maintained, and also as Crossref allows a down link from the DOI handle to the DOI ‘buddy’ handle (a ‘see also’ type link) could be established thus pairing off these two handles. (Of course, additional values whether held in the DOI resolution record or especially in an associated DOI ‘buddy’ record would be subject to common typing constraints for semantic interoperability.)
My personal feeling is that public data is best exposed via a public resolution record with no strings attached. That is the surest way to guarantee both data persistence and accessibility.

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.

Handle System Workshop

Tony Hammond — Fri, 20 Jun 2008 00:00:00 +0000

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. (The OpenHandle work makes the Handle and DOI systems more readily acessible to applications.)

Other speakers were Norman Paskin (IDF), Gordon Dunsire (Centre for Digital Library Research, University of Strathclyde), Brian Green (Editeur), Jill Cousins (European Digital Library Foundation), Jan Brase (TIB, Germany), Larry Lannom (CNRI), Ed Pentz (Crossref), Nigel Ward (Link Affiliates), and Dan Broeder (CLARIN/MPG).

The agendas for the two meetings are posted here (DOI) and here (Handle).

PubMed Central Links to Publisher Full Text

Ed Pentz — Thu, 12 Jun 2008 00:00:00 +0000

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. Almost all of the PMC articles contain DOIs but they aren’t linked. This seems like a waste considering that publishers have invested a lot in Crossref and DOIs as unique identifiers and persistent links.

This issue will be of interest to anyone who publishers journal articles that are the result of NIH funding and fall under the NIH Public Access Policy.

Robots: One Standard Fits All

Tony Hammond — Wed, 04 Jun 2008 00:00:00 +0000

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.

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?

Dark Side of the DOI

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

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

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

Tombstone

Tony Hammond — Fri, 23 May 2008 00:00:00 +0000

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

Alas, poor XRI. But what might this also mean for other URI schemes (note the reference above to “http: URIs)? Well, the message starts out with this:

“In The Architecture of the World Wide Web 1 the TAG sets out the reasons why http: URIs are the foundation of the value proposition for the Web, and should be used for naming on the Web. “

Now I’m not sure that this is quite what AWWW actually says. I don’t find it to be that insistent that “http” URIs … should be used for naming on the Web” but I would need to read it more carefully. Certainly, “http: URIs” fit the bill and are top of the class. But there is also a general recognition that other schemes than “http:” do exist.

Interesting times anyway with a “winner takes all” approach to identification. I wonder what this all means for DOI.

Metadata Reuse Policies

Tony Hammond — Tue, 20 May 2008 00:00:00 +0000

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.

Time to put the caveats aside and focus on the actuals.

Nature’s Metadata for Web Pages

Tony Hammond — Mon, 19 May 2008 00:00:00 +0000

Well, we may not be the first but wanted anyway to report that Nature has now embedded metadata (HTML meta tags) into all its newly published pages including full text, abstracts and landing pages (all bar four titles which are currently being worked on). Metadata coverage extends back through the Nature archives (and depth of coverage varies depending on title). This conforms to the W3C’s Guideline 13.2 in the Web Content Accessibility Guidelines 1.0 which exhorts content publishers to “provide metadata to add semantic information to pages and sites”.

Metadata is provided in both DC and PRISM formats as well as in Google’s own bespoke metadata format. This generally follows the DCMI recommendation “Expressing Dublin Core metadata using HTML/XHTML meta and link elements, and the earlier RFC 2731 “Encoding Dublin Core Metadata in HTML”. (Note that schema name is normalized to lowercase.) Some notes:

The DOI is included in the “dc.identifier” term in URI form which is the Crossref recommendation for citing DOI.
- We could consider adding also “prism.doi” for disclosing the native DOI form. This requires the PRISM namespace declaration to be bumped to v2.0. We might consider synchronizing this change with our RSS feeds which are currently pegged at v1.2, although note that the RSS module mod_prism currently applies only to PRISM v1.2.
  - We could then also add in a “prism.url” term to link back (through the DOI proxy server) to the content site. The namespace issue listed above still holds.
    - The “citation_” terms are not anchored in any published namespace which does make this term set problematic in application reuse. It would be useful to be able to reference a namespace (e.g. “rel="schema.gs" href="..."“) for these terms and to cite them as e.g. “gs.citation_title“.
    The HTML metadata sets from an example landing page are presented below.

If you view the page source you should see something like the text below. (Note that you may have to scroll past whitespace which is emitted by the HTML template generator.)

 <pre>&lt;link title="schema(DC)" rel="schema.dc" href="http://purl.org/dc/elements/1.1/" /&gt;

 While it is not expected that search engines will index these terms directly and that no direct SEO is intended, we think there is enough value for applications to make use of these terms. The terms are reasonably accessible to simple scripts, etc. Note that even in [RFC 2731][4] (published in 1999) there is a Perl script listed in Section 9 which allows the metadata name/value pairs to be easily pulled out. Running this over the example page yields the following output:
<pre>@(urc;

@|MISSING ELEMENT NAME; text/css @|MISSING ELEMENT NAME; text/html; charset=iso-8859-1 @|robots; noarchive @|keywords; Nature, science, science news, biology, physics, genetics, astronomy, astrophysics, quantum physics, evolution, evolutionary biology, geophysics, climate change, earth science, materials science, interdisciplinary science, science policy, medicine, systems biology, genomics, transcriptomics, palaeobiology, ecology, molecular biology, cancer, immunology, pharmacology, development, developmental biology, structural biology, biochemistry, bioinformatics, computational biology, nanotechnology, proteomics, metabolomics, biotechnology, drug discovery, environmental science, life, marine biology, medical research, neuroscience, neurobiology, functional genomics, molecular interactions, RNA, DNA, cell cycle, signal transduction, cell signalling. @|description; Nature is the international weekly journal of science: a magazine style journal that publishes full-length research papers in all disciplines of science, as well as News and Views, reviews, news, features, commentaries, web focuses and more, covering all branches of science and how science impacts upon all aspects of society and life. @|dc.publisher; Nature Publishing Group @|dc.language; en @|dc.rights; #169; 2008 Nature Publishing Group @|dc.title; Crystal structure of squid rhodopsin @|dc.creator; Midori Murakami @|dc.creator; Tsutomu Kouyama @|dc.identifier; doi:10.1038/nature06925 @|prism.copyright; © 2008 Nature Publishing Group @|prism.rightsAgent; permissions@nature.com @|prism.publicationName; Nature @|prism.issn; 0028-0836 @|prism.eIssn; 1476-4687 @|prism.volume; 453 @|prism.number; 7193 @|prism.startingPage; 363 @|prism.endingPage; 367 @|citation_journal_title; Nature @|citation_publisher; Nature Publishing Group @|citation_authors; Midori Murakami, Tsutomu Kouyama @|citation_title; Crystal structure of squid rhodopsin @|citation_volume; 453 @|citation_issue; 7193 @|citation_firstpage; 363 @|citation_doi; doi:10.1038/nature06925 @)urc;

DOIs and PubMed Central - why no links?

Ed Pentz — Wed, 14 May 2008 00:00:00 +0000

Further to my previous post “NIH Mandate and PMCIDs” we’ve been looking into linking to articles on publishers’ sites from PubMed Central (PMC). There are a couple of ways this happens currently (see details below) but these are complicated and will lead to broken links and more difficulty for PMC and publishers in managing the links. Crossref is going to be putting together a briefing note for its members on this soon.

The main issue we are raising with PMC, and that we will encourage publishers to raise too, is why doesn’t PMC just automatically link DOIs? Most of the articles in PMC have DOIs so this would require very little effort from PMC and no effort from publishers and would give readers a perisistent link to the publisher’s version of an article.

Current PMC linking methods. 1) Links on Author Manuscripts in PMC are pulled in from PubMed’s LinkOut service which requires the publisher to register with PubMed and provide linking files. The DOI can be specified as the linking mechanism via LinkOut.

For final version of articles in PMC the journal image at the top of the page can be linked to the journal homepage or can have a “this article” link to the publisher’s site. The publisher has to sign up with PMC for specifying the header graphic and the links. https://web.archive.org/web/20080916065531/http://www.pubmedcentral.nih.gov.pluma.sjfc.edu/pmcdoc/pubsetup.doc (word doc) say “The static base (http://www.biomedcentral.com/) of the URLs for this link comes from the HTML template. PMC then dynamically completes the URL by adding an issn/vol/page. ” and then says that any item in the XML (such as the DOI) can be used.

Both of the approaches outlined above require extra work and will be difficult for smaller publishers. In addition, the links will be fragile by not being based on DOIs. Publishers can specify that DOIs can be used but it isn’t easy. We’d like to leverage the resources that publishers have already put into the DOI system but automatically making the DOIs active links - it would be very easy.

OpenHandle: Languages Support

Tony Hammond — Mon, 21 Apr 2008 00:00:00 +0000

Following up the earlier post on OpenHandle, there are now a number of language examples which have been contributed to the project. The diagram below shows the OpenHandle service in schematic with various languages support. Briefly, OpenHandle aims to provide a web services interface to the Handle System to simplify access to the data stored for a given Handle.

(Note that the diagram is an HTML imagemap and all elements are “clickable”.)

Note: this diagram is no longer available online as of 2023. We show the code here for reference.

<map name="GraffleExport">
<area shape=poly coords="302,133,273,117,244,133,266,149,261,157,274,150,302,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeLisp"> <area shape=poly coords="359,93,330,77,302,93,324,109,318,117,332,110,359,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeFSharp"> <area shape=poly coords="186,93,157,77,129,93,151,109,145,117,159,110,186,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeAppleScript"> <area shape=poly coords="244,93,215,77,186,93,208,109,203,117,217,110,244,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeCSharp"> <area shape=poly coords="244,174,215,157,186,174,208,189,203,197,217,190,244,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodePython"> <area shape=poly coords="244,133,215,117,186,133,208,149,203,157,217,150,244,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeJavaScript"> <area shape=poly coords="186,174,157,157,129,174,151,189,145,197,159,190,186,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodePhp"> <area shape=poly coords="302,93,273,77,244,93,266,109,261,117,274,110,302,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeErlang"> <area shape=poly coords="359,133,330,117,302,133,324,149,318,157,332,150,359,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodePerl"> <area shape=poly coords="302,174,273,157,244,174,266,189,261,197,274,190,302,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeRuby"> <area shape=poly coords="359,174,330,157,302,174,324,189,318,197,332,190,359,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeSmalltalk"> <area shape=poly coords="186,133,157,117,129,133,151,149,145,157,159,150,186,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeJava"> <area shape=poly coords="255,237,255,260,266,260,244,272,222,260,233,260,233,237,222,237,244,225,266,237,255,237" href="http://www.ietf.org/rfc/rfc2616.txt"> <area shape=poly coords="174,527,174,495,196,491,217,495,217,527,196,531,174,527" href="http://hdl.handle.net/"> <area shape=poly coords="270,527,270,495,292,491,314,495,314,527,292,531,270,527" href="http://hdl.handle.net/"> <area shape=poly coords="152,268,210,268,210,300,152,304,152,268" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=rdf"> <area shape=poly coords="201,307,258,307,258,339,201,343,201,307" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=n3"> <area shape=poly coords="267,297,325,297,325,329,267,333,267,297" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=json"> <area shape=poly coords="255,426,255,450,266,450,244,461,222,450,233,450,233,426,222,426,244,414,266,426,255,426" href="http://www.ietf.org/rfc/rfc3651.txt"> <area shape=poly coords="262,355,262,388,226,388,226,355,262,355" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=rdf"> <area shape=poly coords="277,223,292,208,320,208,344,220,330,235,301,235,277,223" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10.1000/1&#038;mimetype=text/plain&#038;format=json"> <area shape=poly coords="148,244,162,229,191,229,215,241,201,256,172,256,148,244" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=json"> <area shape=poly coords="222,507,222,475,244,471,266,475,266,507,244,511,222,507" href="http://hdl.handle.net/"> <area shape=poly coords="49,215,89,102,191,62,305,79,401,143,393,282,315,350,198,363,105,317,49,215,120,481,140,501,178,501,199,474,186,442,152,436,122,447,120,481,49,215,57,569,79,571,89,547,71,534,53,548,57,569,49,215,57,569" href="http://code.google.com/p/openhandle/">
</map>

NIH Mandate and PMCIDs

Ed Pentz — Tue, 15 Apr 2008 00:00:00 +0000

The NIH Public Access Policy says “When citing their NIH-funded articles in NIH applications, proposals or progress reports, authors must include the PubMed Central reference number for each article” and the FAQ provides some examples of this:

Examples:

Varmus H, Klausner R, Zerhouni E, Acharya T, Daar A, Singer P. 2003. PUBLIC HEALTH: Grand Challenges in Global Health. Science 302(5644): 398-399. PMCID: 243493

Zerhouni, EA. (2003) A New Vision for the National Institutes of Health. Journal of Biomedicine and Biotechnology (3), 159-160. PMCID: 400215

It’s interesting to note that on PMC itself both the [The NIH Public Access Policy says “When citing their NIH-funded articles in NIH applications, proposals or progress reports, authors must include the PubMed Central reference number for each article” and the FAQ provides some examples of this:

Examples:

Varmus H, Klausner R, Zerhouni E, Acharya T, Daar A, Singer P. 2003. PUBLIC HEALTH: Grand Challenges in Global Health. Science 302(5644): 398-399. PMCID: 243493

Zerhouni, EA. (2003) A New Vision for the National Institutes of Health. Journal of Biomedicine and Biotechnology (3), 159-160. PMCID: 400215

It’s interesting to note that on PMC itself both the][3] - but the DOI isn’t linked. Two things occur to me - 1) should Crossref map DOIs to PMCIDs and vice versa and make PMCIDs available in it’s query interfaces and 2) shouldn’t publishers ask that the PMC copy of the article link back to the publisher version? It would be very easy with the DOI.

Word Add-in for Scholarly Authoring and Publishing

Crossref — Wed, 26 Mar 2008 00:00:00 +0000

Last week Pablo Fernicola sent me email announcing that Microsoft have finally released a beta of their Word plugin for marking-up manuscripts with the NLM DTD. I say “finally” because we’ve know this was on the way and have been pretty excited to see it. We once even hoped that MS might be able to show the plug-in at the ALPSP session on the NLM DTD, but we couldn’t quite manage it.

The plugin is targeted at production/editorial staff, but, of course, it will be interesting to see if any of this work can be pushed back to the author. I won’t hold my breath on the latter score, but it will be fun to watch.

One thing I would note is that the NLM DTD can also be used in the humanities and social sciences, so, frankly, I think they should market it more broadly.

Anyway- the plugin can be downloaded from the Microsoft site.

And Pablo has setup a blog where testers can discuss the add-in.

And there is also an entry for the project on the Microsoft Research site (an interesting place to peruse, if you have a moment).

Congatulations to Pablo and his team.

OpenHandle: Google Code Project

Tony Hammond — Fri, 07 Mar 2008 00:00:00 +0000

Just announced on the handle-info and semantic-web mailing lists is the OpenHandle project on Google Code. This may be of some interest to the DOI community as it allows the handle record underpinning the DOI to be exposed in various common text-based serializations to make the data stored within the records more accessible to Web applications. Initial serializations include RDF/XML, RDF/N3, and JSON.

We’d be very interested in receiving feedback on this project - either on this blog or over on the project wiki.

Object Reuse and Exchange

Chuck Koscher — Wed, 05 Mar 2008 00:00:00 +0000

On March 3rd the Open Archives Initiative held a roll out meeting of the first alpha release of the ORE specification (http://www.openarchives.org/ore/) . According to Herbert Van de Sompel a beta release is planned for late March / early April and a 1.0 release targeted for September. The presentations focused on the aggregation concepts behind ORE and described an ATOM based implementation. ORE is the second project from the OAI but unlike its sibling PMH it is not exclusively a repository technology. ORE provides machine readable manifests for related Web resources in any context. For instance, DOI landing pages (aka splash page) are human readable resources containing links to any number of resources related to the work identified by the DOI. An ORE instance for the DOI (called a Rem or resource map) would describe the same set of resources in a machine friendly format. A standardized form of redirection understood by the DOI proxy would yield the Rem instead of normal page e.g.

http://dx.doi.org.pluma.sjfc.edu/10.5555/abcd?type=rem which could be useful for crawlers.

A second roll out meeting is planned during the Sparc-08 workshops in early April.

ISO/CD 26324 (DOI)

Tony Hammond — Fri, 22 Feb 2008 00:00:00 +0000

Following on from my previous post about prism:doi I didn’t mention, or reference, the ongoing ISO work on DOI, Indeed I hadn’t realized that the DOI site now has a status update on the ISO work:

_“The DOI® System is currently being standardised through ISO. It is expected that the process will be finalised during 2008. In December 2007 the Working Group for this project approved a final draft as a Committee Draft (standard for voting) which is now being processed by ISO. Copies of the Committee Draft (SC9N475) and an accompanying explanatory document detailing issues dealt with during the standards process (SC9N474) are provided here for information.

Committee Draft 26324 is subject to ISO’s copyright and is for information only to those interested in the project; it may not be re-distributed. This is currently undergoing the formal ISO voting process; the deadline for comments on CD 26324 from TC46/SC9’s national bodies is April 25, 2008: please contact your national member of ISO TC46/SC9 if you would like it contribute to comments on this draft standard. Other documents for the ISO DOI Working Group are available on a DOI Project Register.”_

prism:doi

Tony Hammond — Fri, 22 Feb 2008 00:00:00 +0000

The new PRISM spec (v. 2.0) was published this week, see the press release. (Downloads are available here.)

This is a significant development as there is support for XMP profiles, to complement the existing XML and RDF/XML profiles. And, as PRISM is one of the major vocabularies being used by publishers, I would urge you all to go take a look at it and to consider upgrading your applications to using it.

One caveat. There’s a new element <tt>prism:doi</tt> (PRISM Namespace, 4.2.13) which sits alongside another new element <tt>prism:url</tt> (PRISM Namespace, 4.2.55). Unfortunately the <tt>prism:doi</tt> element is shown to take DOI proxy URL as its value - and not the DOI string itself, e.g.

Model #1
<prism:doi rdf:resource=”http://dx.doi.org.pluma.sjfc.edu/10.1030/03054”/>
Model #2
<prism:doi>http://dx.doi.org.pluma.sjfc.edu/10.1030/03054</prism:doi>

This seems to me to just plain wrong. The DOI in itself is not a URL (or URI) - although can, and should, be represented in URI form when used in Web contexts (i.e. pretty much most of the time). As a literal it should be used in its native form as specified in ANSI/NISO Z39.84 - 2005 Syntax for the Digital Object Identifier. This would only satisfy Model #2 above.

To satisfy Model #1 above a URI form for DOI would be required. And this is not the service URI denoted by the proxy. It would either have to be:

Model #1 - Registered URI Form
<prism:doi rdf:resource=”info:doi/10.1030/03054”/> * Model #1 - Unregistered URI Form
<prism:doi rdf:resource=”doi:10.1030/03054”/>

Any comments? Some guidelines from Crossref would be useful - although maybe further discussion is required. It is, of course, a constant bugbear that “doi:” remains an unregistered URI scheme.

Added XML format parameter to Crossref’s OpenURL resolver

Chuck Koscher — Wed, 13 Feb 2008 00:00:00 +0000

From the beginning our OpenURL resolver has had a non standard feature of returning metadata in response to a request instead of redirecting to the referrent. This feature returned one of our older XML formats which is a bit limited as to the fields it contains.

Sometime after our resolver was deployed we introduced a more verbose XML format for DOI metadata called ‘UNIXREF”. This was always available to regular queries against the Crossref system but was never introduced to the OpenURL resolver (for no particular reason).

We’ve since learned that some user’s are relying on the OpenURL’s metadata feature to build proper references in situations where they have a DOI and that the older XML format is insufficient. Therefor I’ve added a ‘format’ parameter to our OpenURL resolver which allows one to request the more verbose UNIXREF. (see www.crossref.org/openurl)

As always please feel free to contact us regarding new features or changes to existing features that might be helpful.

Regards,

Chuck

Crossref Citation Plugin (for WordPress)

Crossref — Sat, 09 Feb 2008 00:00:00 +0000

OK, after a number of delays due to everything from indexing slowness to router problems, I’m happy to say that the first public beta of our WordPress citation plugin is available for download via SourceForge. A Movable Type version is in the works.

And congratulations to Trey at OpenHelix who became laudably impatient, found the SourceForge entry for the plugin back on February 8th and seems to have been testing it since. He has a nice description of how it works (along with screenshots), so I won’t repeat the effort here.

Having said that, I do include the text of the README after the jump. Please have a look at it before you install, because it might save you some mystification.

Description

A WordPress plugin that allows you to search Crossref metadata using citations or partial citations. When you find the reference that you want, insert the formatted and DOI-linked citation into your blog posting along with supporting COINs metadata. The plugin supports both a long citation format and a short (op. cit.) format.

Warnings, Caveats and Weasel Words

Please note the following about this plugin:

We are releasing this as a test. It is running on R&D equipment in a non-production environment and so it may disappear without warning or perform erratically. If it isn’t working for some reason, come back later and try again. If it seems to be broken for a prolonged period of time, then please report the problem to us via sourceforge.
There is currently a 20 item limit on the number of hits returned per query. This might seem arbitrary and stingy, but please remember- we are not trying to create a fully blown search engine- we’re just trying to create a citation lookup service. Of course, if, after looking at how the service is used, it looks like we need to up this limit, we will.
If you look in the plugin options (or at the code), you will see that the system includes an API key. At the moment we have no restrictions on use of this service, but have included this in case we need to protect the system from abuse.
The bulk of the functionality we have developed is actually at the back-end. This plugin is just a lightweight interface to that back-end. You can examine the guts of the plugin in order to easily figure out how to create similar functionality for your favorite blog platform, wiki, etc. If you do create something, please let us know. We’d love to see what people are building.
We are continuing to experiment with the metadata search function in order to increase its accuracy and flexibility. Again, this might result in seemingly inconsistent behavior. Did we mention that this is a test?
Please note that this API is not meant for bulk harvesting of Crossref metadata. If you need such facilities, then please look at our web site for information about our metadata services.
The data currently behind the plugin is *just* a December 2007 snapshot of our our complete journal article metadata. We have not added books or proceedings yet. We will do so soon and we will start updating the metadata weekly.

We welcome your ideas for tools that we can provide to help researchers. Please, please, please send comments, requests, queries and ideas to us at:

citation-plugin@crossref.org

CLADDIER Final Report

Crossref — Tue, 15 Jan 2008 00:00:00 +0000

I just ran across the final report from the CLADDIER project. CLADDIER comes from the JISC and stands for “CITATION, LOCATION, And DEPOSITION IN DISCIPLINE & INSTITUTIONAL REPOSITORIES”. I suspect JISC has an entire department dedicated to creating impossible acronyms (the JISC Acronym Preparation Executive?)

Anyhoo- the report describes a distributed citation location and updating service based on the linkback mechanism that is widely used in the blogging community.

I think this is an interesting approach and is one that I talked about briefly (PDF) at the UKSG’s Measure for Measure seminar last June. I think that, like most proponents of p2p distributed architectures, they massively underestimate the problem of trust in the network. They fully knowledge the problem of linkback spam, but their hand-wavy-solution(tm) of using whitelists just means the system effectively becomes semi-centralized again (you have to have trusted keepers of the whitelists).

And of course I was mildly exasperated by the report’s characterization of one of the perceived “disadvantages” of the Crossref architectural model being a :

“Centralised service hosting a large persistent store – with the need for a (possibly commercial) business model to justify providing the service.”

Though DOI registries like Bowker and Nielsen Bookdata are commercial, Crossref, the organisation that services the industry that the JISC is concerned with, is *not* a commercial service.

Also if you replaced the phrase “justify providing” with the word “sustain”, the sentence wouldn’t sound like such a “disadvantage.”

But aside from these quibbles, the report makes an interesting (if technical) read.

BISG Paper on Identifying Digital Book Content

Ed Pentz — Mon, 14 Jan 2008 00:00:00 +0000

BISG and BIC have published a discussion paper called “The identification of digital book content” - https://web.archive.org/web/20090920075334/http://www.bisg.org/docs/DigitalIdentifiers_07Jan08.pdf. The paper discusses ISBN, ISTC and DOI amongst other things and makes a series of recommendations which basically say to consider applying DOI, ISBN and ISTC to digital book content. The paper highlights in a positive way that DOI and ISBN are different but can work together (the idea of the “actionable ISBN” and aiding discovery of content). However, it doesn’t go into much depth on any of the issues or really explain how all these identifiers would work together and the critical role that metadata plays.

Nevertheless it’s great that the paper has been put forward as a discussion document - Crossref plans to respond and be part of the ongoing discussion in this area.