I am not sure it's becuase the standard is less specific than you
suggest, because I don't understand the standard, or because the
standard is not followed, but I can not use second indicator 0 to
reliably indicate full text. I have 856's with second indicator 0 that
are NOT full text, and those without second indicator 0 that are. Links
that are full text if and only if second indicator is 0 are a small
minority of all 856's in my catalog.
On 6/2/2011 9:05 AM, Mitchell, Michael wrote:
> I've got our 856$y mapped to display as a linked note. I'd much rather display a clickable note such as "Click here for online full-text" from $y than a URL like http://www.adl.org/education/curriculum_connections/lewis_clark_art_gallery.asp?cc_section=lewis_clark_art_gallery from $u. No brainer to me. I could map the z or 3 but it's just as easy to change them all to y. Macros are our friends.
> As for figuring out if the resource is full text or whatever, that is partly the job of the second indicator in conjunction with the bib record (856 40 means URL is for the whole described resource). I'm sure y'all know this but the discussion seems to be obscuring the obvious as this list's discussions often do.
>
>
> Michael Mitchell
> Technical Services Librarian
> Brazosport College
> Lake Jackson, TX 77566
> michael.mitchell at brazosport.edu
>
>
>
> -----Original Message-----
> From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind
> Sent: Wednesday, June 01, 2011 5:17 PM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] MARC 856 question
>
> 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 Thu Jun 02 2011 - 12:29:41 EDT