PURL Pilot:
A Proposal

Document J1

Proposal:

That a group of CONSER participants test the concept of maintenance of URLs through an OCLC-hosted cooperative PURL server. The pilot would be conducted with the intention that, if successful, a recommendation would be passed to PCC regarding possible use of a PURL server for records maintained by BIBCO/CONSER institutions.

Summary:

URL maintenance is one well-known area of concern for all records with 856 fields. While some BIBCO/CONSER cataloging agencies have maintenance procedures that include update of OCLC records, others may only maintain URLs in the 856 field in a local OPAC or may lack systematic maintenance procedures. Even if a BIBCO/CONSER participant does complete periodic maintenance, the corrections only immediately benefit OCLC and the participant's OPAC. Each other local catalog holding the record must be separately maintained.

PURLs could be used in place of the URLs used in the 856 field, subfield $u of OCLC records. The anticipated benefit would be reduction of maintenance efforts and expense across various local files. Rather than iteration-by-iteration maintenance, the URL would be maintained in one database: the PURL server.

Institutions such as University of California San Diego have successfully implemented PURLs on a local or regional scale. Could the PURL strategy be implemented successfully on a wider scale? What are the implications of shared maintenance of URLs through a PURL Server? What are the limitations of this strategy; and what enhancements to the PURL software would be needed in order to successfully expand use?

Several considerations lead us to propose CONSER participants as ideal for testing the cooperative use of an OCLC-hosted PURL Server. First, CONSER by definition works through OCLC. Second, CONSER participants have a well-developed understanding of cooperation and of maintenance. Third, CONSER has a history of developing, documenting, and testing ideas in a timely manner.

Unlike most CONSER pilots, however, we propose that while volunteer institutions would be drawn from among CONSER institutions, the records would not be limited to serials (BLvl "s"). That is, during the pilot, volunteers could create PURLs for serials, integrating resources, and even monographs if desired. This liberal scope for the pilot would provide a richer experience upon which to base a recommendation if the pilot proved successful.

Limitations:

Application of PURLs would be limited to the 856 $u, additional fields to be considered at a future date. PURLs would only be supplied in place of URLs included in the OCLC master record, not institution-specific URLs.

It would be understood that the initial version of the cooperative PURL server would reflect a largely "as is" state of PURL software capabilities:

It may require a login ID and password distinct from the standard OCLC cataloging login/password (N.B. OCLC staff will investigate whether an interim workaround could be affected so that the same login/password might be used on both systems)
Access to the PURL server would be separate and distinct from OCLC systems. OCLC support, etc. would be limited. The system would be considered experimental.
PURLs general capabilities such as reporting would be accepted as is (OCLC would consider enhancements in the future).

The cooperative PURL server naming convention would use the name "pcc" in anticipation that the server may scale to all-CONSER and eventually BIBCO use.

The pilot would include an exit strategy, and volunteer libraries would be aware of their responsibilities to gracefully exit the PURL pilot test, should the test not lead to PURLs as a technique of choice.

Issues:

Are there categories of URI's (e.g., URNs, DOIs) not appropriate for the pilot?

What are the capabilities of PURL software as is? Esp. with regards to reporting failed URLs, duplicate registration of a URL to multiple PURLs, etc.

Pilot details:

How often should the validation software be run?
How would volunteers know which PURLs to maintain? (For CORC participants, the current validation report could be used, assuming that an institution set "validate" to "yes"; but what about OCLC WorldCat?)
Would the PURLs be simply substituted for URLs, or would it be better to move the URLs to a 530 field (as GPO does)?
What would be done about denial of access web sites (web sites that refuse access by robots)?
What should be done about URLs no longer valid (see: http://uclibs.org/PID/4404 for possible strategy)

Related URLs:

http://www.purl.org/

http://www.ics.uci.edu/pub/ietf/http/rfc1945.html#Status-Codes

http://uclibs.org/maint/validate/status-codes.html

Appendix: Report of CONSER Survey

In the fall of 2000, a CONSER sub-group (consisting of: Les Hawkins, Tom Champagne, Becky Culbertson, David Van Hoy, Steve Shadle, Naomi Young, and Valerie Bross) developed a survey and polled CONSER institutions regarding various aspects of URLs. As is evident in this summary of the count questions, there is strong support for developing some mechanism for cooperative maintenance of 856 subfield $u data.

Summary Table of Responses (minus comments)

created 010425 Becky Culbertson & Valerie Bross; with assistance from Les Hawkins, Tom Champagne, David Van Hoy, Steve Shadle, Naomi Young. Mentioning all of these all these people is simply a means of expressing thanks; it is not meant to imply any support for the ideas expressed here.