Print

Print


Greta--

There is further information about wording for this when withdrawing/deactivating BibPurls which could apply to URLs in general.  The relevant information is on p. 9 and 10 of the URL below

http://libraries.universityofcalifornia.edu/hots/conser/purldocumentation.pdf 

Becky

-----Original Message-----
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Greta de Groat
Sent: Monday, May 21, 2012 8:51 AM
To: [log in to unmask]
Subject: [PCCLIST] Question re invalid URLs in 856

I have a question about PCC practice for the URLs for internet resources that are no longer available.

LRI 9.7B says the following

2) If searching indicates that the resource is no longer available, create a note to reflect this fact by changing subfield $u in field 856 to subfield $z and modifying the subfield to show that the resource is no longer available, indicating the last date that the resource was searched. ...

and gives the example
revised record
856 41 $z Electronic address (http://www.example.com) not available when searched on [date]

However CONSER cataloging module module 31 (dated March 2012) says:

If the only link appearing on the CONSER record is an invalid link, it can be left on the record and labeled as invalid in the subfield $z of the 856 field. Note that the second indicator is blank and that the non-working URL is maintained in subfield $u of the 856. This coding differs from LC practice documented in LCRI 9.7B where the non-working URL is moved to a subfield z so that it does not appear on LC’s link checking reports repeatedly. The example below is based on a recommendation from OCLC and is derived from current system indexing needs and OCLC'€™s electronic address checking software (see OCLC'€™s recommendation at: 
http://www.oclc.org/support/documentation/worldcat/cataloging/electronicresources/).
856 4# $z Link no longer valid as of Dec. 4, 2000 $u http://www...

So, we're confused about which practice to follow, since it seems that there are two conflicting PCC practices. This is also causing us problems internally in our opac, since we can't suppress the display of a hotlink if the URL is in $u. And we don't quite understand why one would use a public rather than non-public note ($x) for this.


Thanks
Greta de Groat
Stanford University Libraries