Blog

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.

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

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.

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

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

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…