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.

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

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

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.

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.

var f = function (OpenHandleJson) {   var h = new OpenHandle(OpenHandleJson);   var hv = h.getHandleValues();   for (var i = 0; i < hv.length;

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.

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.

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.

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.

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