Blog

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.

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 organization to formalize a public spec.

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:

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

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

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())     }   } }

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.

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

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:

1. Abstract Protocol Definition  (APD)
   • Binding for SRU 1.2
     • Auxiliary Binding for HTTP GET
       • CQL 1.2

         • Binding for OpenSearch

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