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.
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
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
It would be understood that the initial version of the cooperative PURL
server would reflect a largely "as is" state of PURL software capabilities:
The cooperative PURL server naming convention would use the name "pcc"
in anticipation that the server may scale to all-CONSER and eventually
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
PURLs general capabilities such as reporting would be accepted as is (OCLC
would consider enhancements in the future).
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.
Are there categories of URI's (e.g., URNs, DOIs) not appropriate for the
What are the capabilities of PURL software as is? Esp. with regards to
reporting failed URLs, duplicate registration of a URL to multiple PURLs,
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)
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.
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.