Page History

...

Marty had researched the second generation PURL service software project at OCLC (see Purlz Initiative (OCLC and Zepheira)). 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 PURLZ 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 PURLZ 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. If contact can be made and looks promising, Simeon and Brian will look at the structure of the new implementation and assess whether it makes sense for Brian to do a local test implementation.

We also briefly 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.

Harvard Name Resolution Service

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.

Handles

Bill asked whether the group had ruled out consideration of the Handle System at a previous meeting; while we have been moving to think of the resolution service without a set of richer accompanying metadata and services, the Handle service has worked well for eCommons and LSDI.
Bill has wanted to host a mirror of the local Handle server and Mann would be a logical place to do so. He will talk to Chris Manly from DLIT to see when it might be possible for Chris to work with Bill Klinko and John Cline at Mann to do a second installation for redundant resolution of Cornell handles.
To evaluate the Handle System further it would be helpful to know the memory footprint of a Handle record (Bill?) and to create a test suite to load ~1 million records and conduct load tests on resolution performance.

Timetable

Given current projects underway in DLIT and ITS, completing an evaluation/load test of the Handle System and equivalent testing of the PURLZ and/or Harvard NRS system by the end of the calendar year is the most optimistic scenario for implementation. If the PURLZ and Harvard projects have data on scalability and load testing that would be helpful in our evaluation.