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.

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.

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.

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

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.

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.

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.

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