URL labels on ref. items: summ. & clarification

[Steve Morris]

Thanks to all those who responded to my question a while back.

Original question:

What's a good strategy for maintaining URL labels on non-circulating
hardcopy reference items that have web-based counterparts (as in how best to
keep links up-to-date while minimizing physical processing and relabeling
requirements)?  And would using PURL's for this would be a good idea?

Clarification:

Since about half of the respondents indicated that my problem would be
solved just by putting the URL in the bib record I should clarify that I am
trying to address an additional issue.  The idea is to provide the patrons
with visual cues and prompts that point to resources that the patrons might
not have even thought about looking for--to provide a "tangible item >> Web"
link.  In a non-circulating reference shelf context these are hard copy
resources (statistics, manuals, etc.) that a patron usually physically
locates either in shelf browse mode (the reference area is divided into very
specific subject areas), under reference librarian direction, or on the
basis of familiarity from previous or frequent usage.  In these cases, the URL
in the OPAC won't be seen by the user since the OPAC is not the access
point.  And it doesn't seem that the combination of  a) patron awareness of
web resources and b) the creation a critical mass of web-based versions of
previously-existing resources has yet reached the point where the patron
would strongly consider making a followup OPAC search just to see if there
is a URL.  Since these items are non-circulating, a) the hard copies serve as
reliable placeholders for pointers b) the URL label provides added value
since the user cannot check the item out.

My query arose out of a concern that URL changes will have a more
significant and problematic impact on label upkeep than on bib record upkeep
since there are additional physical processing components that muck up
workflows outside of bib record/URL maintenance.  I was hoping someone had a
silver-bullet solution to maintenance.  I would prefer just to have to worry
about maintaining the URL's once each in a database and--instead of worrying
about relabelling--have script(s) update each instance of the URL.

As an aside, I find it interesting that I see a lot of discussion of how to
use the Web to simulate shelf browsing but little on how to provide links
from the actual physical shelf browsing process back to the Web.

Responses: 

Nobody actually said that they were labeling the hard copies.  Labelling
suggestions fell into 3 categories of about equal frequency:

1) point to a page of my own and use a redirect mechanism of some sort

   I had originally indicated that I might simply provide a link to a page
of my own that would be easire to maintain since I--after URL validation &
relocation--could just have a script update of the link on that page rather
than need to go find each hard copy, relabel it, and mess around with sticky
tape and stuff.  One suggestion was to put a number on the item that the
patron could use to look up the item--but again there is an additional
degree of separation involved.  A variation on this I've toyed with is to
provide a URL that is a link to a page of my own--and add an "#" with a
mnemonic name or simple code on the end that takes the person immediately to
the area of the proper link on the intermediate page.

2) use the actual URL's on the assumption that they will be stable enough

   Actually, the resources I'm tracking are still fairly mobile, depending
on how deeply I try to point into site structures.  Shallow depth URL's are
somewhat more stable but increase the degrees of separation of patron access
to specific resources.   Despite the problems of URL degradation I like the
idea of using actual URL's because a) if the specific URL doesn't work the
patron can at least try to work their way towards the item by truncating the
URL to a viable stem, and b) I think that URL's pass a little bit of subtle
information of their own (on the basis of familiarity with a site: whether
to turn off graphics, whether Monday 9 AM is really a good time to access, etc.)
   
3) use PURL's

   I'd like to learn a bit more about PURL resolution performance first.
And unless the original URL is built into the PURL (and easily identifiable
as such) there would be the loss of the subtle information that the original
URL imparts.  One option would be to put both the original URL and the PURL
on the label.  One problem: not being familiar with the resolver, I'm not
sure if PURL updating could be automated by a script in batch sessions.

In sum:  Still no silver bullet solutions.  In the short term I think we'll
continue to use the actual URL's--in the long term, ??? still thinking.

Steve

------------------------------------------------------------------------------
Steve Morris, Technical Services Librarian
Harmer E. Davis Transportation Library
Institute of Transportation Studies, U.C. Berkeley
e-mail: smorris at library.berkeley.edu
phone: (510) 642-3604    fax: (510) 642-9180
http://www.lib.berkeley.edu/ITSL/smorris.html