And this is, of course, not unique to Jonathan's collection.
856 40 indicates that the link it to the resource, but not necessarily the *whole* resource. For some reason, table of contents links are coded that way as well. They are also (more?) often coded as ind2=1 (a version of the resource), but so are many full-text links, so that doesn't help.
Perhaps a cataloger can correct me here. But I suspect the logic is that the table of contents is seen as being a *part* of the resource (a page in the book), and so gets coded as a link to the resource itself, rather than ind2=2 (related resource), as you see with publisher descriptions and author info links.
The TOC link is usually -- although not always -- accompanied by a subfield 3. So you can, to some extent, use ind2 and $3 in combo to rule-out non-full-text links. But now we're basing our determination on a free text field. Not very precise.
A lot of libraries seem to have come-up with a locally defined material type for 'Internet', or similar, and mark their online full-text resources as such. That seems to me to be a better approach than parsing 856's.
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: Next generation catalogs for libraries [NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind [rochkind_at_JHU.EDU]
Sent: Thursday, June 02, 2011 9:29 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] MARC 856 question
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 - 13:55:48 EDT