Agenda
From Dean's 10/21 agenda:
|
One item people might want to take a look at was brought to my attention by MacKenzie Smith during my visit to MIT. Apparently OCLC is working on a follow-on to the original PURLs. This is still a work in progress, but some info is available at: http://prototypo.blogspot.com/2008/02/beyond-redirection-rich-and-active.html |
present: Adam, Bill, Brian, Jon, Marty, Rick, Simeon
Marty will circulate links to the NISO names identifier webinar when they have been posted. The Thomson ResearcherId and ISNI identifiers for individuals are further along than organizational identifiers; while of interest, we do not plan to collect or maintain external identifiers for individuals or organizations as part of this project.
Simeon reviewed the Los Alamos National Lab Id 2-step locator system for their approximately 10,000 aDORe repositories, many of which correspond to an individual ARC file. Resolution speed (~10 milliseconds) is essential since a single page view may require multiple (~10) separate id resolution actions. They maintain some 600 million identifiers, which are converted into a 16-byte md5 hash as the index of a very large MySQL table. The repository id is the only other field in the main resolution table; collisions are resolved via a much smaller 2nd table of repository ids, which also contains the URL of the repository. The system is powered by 4 IBM blade servers having collectively 16 Gb of memory, and was implemented in Java. Hashing the identifiers, while resulting in some collisions that have to be resolved, does support load balancing by the simple mechanism of the leading digits of the hash values.
We concluded this system was too closely linked to the aDORe federated repository design (which had not been implemented at the time Bill and Adam started using aDORe here at Cornell) to be of use for this project. While capable of scaling and very fast, we do not anticipate wanting a 2-stage approach or needing so large an identifier space.
Marty had researched the PURL service software second-generation implementation at OCLC. A February, 2008 blog post by David Wood () characterizes as the most significant improvement the typing of the URLs and the potential to combine PURL resolution with other services. Initially intended to allow returning a variety of status codes (301, 302, 303, 310, 404 and 410), the new PURL service could "combine strong identifiers with rich metadata, providing the building blocks for other semantic applications."
The conceptual design for the new PURL service also goes further to suggest an "active PURL" capable of returning an RDF graph describing a web service, either to provide a more nuanced response or to redirect to different service(s).
At the time of the meeting Marty had not been able to confirm whether the new PURL service is still actively under development. Since the meeting an email from ____ indicates it has been, but primarily as a re-implementation of the features of the original PURL service without new extensions.
It's not clear whether we could have access to the source code.
We discussed Pete Hoyt's local PURL implementation for use in assigning an actionable URL in the 856 field when cataloging records; it was not designed to scale so should not be considered a candidate for this project.
We looked briefly at the Harvard Name Resolution Service Guide, notable for its description of an apparently complete set of administration tools. Bill questioned the continued use of URNs (as names without a specified location) vs. actionable URLs, but otherwise the group felt we should learn more about the implementation and availability of the source code – perhaps Dean has a contact from his recent visit to Harvard.