Weird, I've got a lot more $y's then that, although I haven't counted.
I've got lots of y's, including ones that don't make any sense when used
as link text (even though that's what $y is documented as).
I've also got plenty of of $3's, including $3's that seem to be
intended as link text rather than what $3 is documented for, "Materials
specified" ("view online" is not a "material specified").
Then I've got other $3's that _are_ used for "materials specified", and
thus work dubiously when used as link text.
Oh, then a whole bunch of $z's of course, used in every way you can
think of.
Basically, it's not possible given my actually existing data to provide
any reasonably nice display of 856's. I can't really do anything but
the legacy practice of just displaying all the $3's, $y's, and $z's in
order, exactly as written -- which doesn't really lead to very nice (let
alone very consistent) displays either. But there's just no way to get
any semantics out of actually existing 856's, but a URL, and a whole
bunch of "display notes" with no way to tell what type is what. At least
not with my data. (I do truncate the $u URL to the hostname only on
display, to keep the display from being _completely_ incomprehensible
sea of characters).
And we haven't even mentioned trying to figure out if an 856 is "full
text" or not, so one can tell the user this, since that's what the user
cares about. Also not possible. And it's not like the $3's, $y's, and
$z's can be counted upon to say that; sometimes they do (in a bunch of
inconsistent ways which make the interface look sloppy), sometimes they
don't at all.
On 6/1/2011 5:42 PM, Baksik, Corinna M. wrote:
> I recently analyzed how many times this subfield occurs in our 856 tags to determine whether I should spend any time in configuring our discovery system to display it properly (it does not). We have about 1.2 million instances of the 856 tag, and about 50 of those have subfield y. Many of those were improperly coded and should be subfield 3. We display the contents of subfield u as the link text, except in the result screen where we use a clickable icon that says "online."
>
>
> Corinna Baksik
> Harvard University Library
> Office for Information Systems
> 90 Mt. Auburn St.
> Cambridge, MA 02472
> 617.495.3724
>
>
>> -----Original Message-----
>> From: Next generation catalogs for libraries
>> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind
>> Sent: Tuesday, May 10, 2011 10:30 PM
>> To: NGC4LIB_at_LISTSERV.ND.EDU
>> Subject: Re: [NGC4LIB] MARC 856 question
>>
>> It's completly unpredictable. Actually existing data has a varied motley
>> of inconsistent notes and text spread accross $y, $z, and $3, and actual
>> systems do all manner of things with them. Makes it very difficult to
>> display 856's in any reasonable way at all.
>>
>>
>> ________________________________________
>> From: Next generation catalogs for libraries [NGC4LIB_at_LISTSERV.ND.EDU] on
>> behalf of David Jones [djones_at_SCU.EDU]
>> Sent: Tuesday, May 10, 2011 8:23 PM
>> To: NGC4LIB_at_LISTSERV.ND.EDU
>> Subject: Re: [NGC4LIB] MARC 856 question
>>
>>>>> On 5/10/2011 at 04:58 PM, Karen Coyle<lists_at_KCOYLE.NET> wrote:
>>> I know that this is a "maybe, sortta" kind of question, but in
>>> creating an 856 field that needs a particular display ("Click here
>> for
>>> x"), can I assume that most systems will take that from a 856 $y?
>> Does
>>> anyone use the $i for display?
>> Actually, I don't think either the $y or $i are prominent. Not even LOC
>> thinks that $y is:
>>
>> http://www.loc.gov/marc/856guide.html#data_elements
>> Subfield $y (Link Text). Subfield $y contains link text which is used
>> for display in place of the URL in subfield $u. Often URLs are difficult
>> to read and most systems do not display them to the user. Since subfield
>> $y was not approved until June 2000 (see Proposal 2000-07), there have
>> been various practices in terms of systems using data in the field as
>> link text. Some systems have used subfields $3 or $z in the past for
>> this purpose. It is not clear how widespread the use of subfield $y is
>> since its approval.
>>
>> AFAIK, $i is not meant for public consumption and is probably obsolete.
>> OCLC seems to agree given their one example:
>>
>> http://www.oclc.org/bibformats/es/8xx/856.shtm
>> ‡i Instruction The instruction or command needed for the remote
>> host to process a request.
>> 856 0 uccvma.bitnet ‡ f IR-L ‡ h Listserv ‡ i
>> subscribe
>>
>> AFAIK, most systems still use $z and/or $3 for the public link text.
>>
>> HTH,
>> David
>>
>>
>> _____________________________________________________________________
>> David Jones mailto:djones_at_scu.edu
>> Library Systems Manager http://www.scu.edu/library/
>> University Library fax: 408-551-1805
>> Santa Clara University phone: 408-551-7167
>> 500 El Camino Real
>> Santa Clara CA 95053-0500
>> _____________________________________________________________________
>> Logic must take care of itself.
>> -- Wittgenstein, Notebooks, 1914-196, 22.8.14
Received on Wed Jun 01 2011 - 18:16:53 EDT