I suspect LOC didn't put these data in the MARC record because they
could more easily divide the metadata production workflow among
different groups of staff. Also, they sometimes have links to additional
biographical information about authors, so, theoretically, by linking
they can reuse information there (but I don't think they do). Sometimes,
they also have information from the publishers.
e.g., for http://lccn.loc.gov/92075663
856 41 $3 Table of contents only $u
http://www.loc.gov/catdir/toc/ecip0712/2007007865.html
856 42 $3 Publisher description $u
http://www.loc.gov/catdir/enhancements/fy0730/2007007865-d.html
856 42 $3 Contributor biographical information $u
http://www.loc.gov/catdir/enhancements/fy0734/2007007865-b.html
IMO, this sort of linking is a good thing, but poses the problems you've
mentioned in the current generation of catalogues. In our current
catalogue, they are indistinguishable from our links to eBooks in the
search results screen, and this drives us crazy! Next Generation
catalogues should make more intelligent use of these links, by
harvesting these supplementary data into the local catalogue where they
can be searched and displayed, rather than providing links directly to
the patron. Or by ignoring them altogether, if that's what we feel would
best serve the patron.
I would like to see a richer, more intelligent relation between these
links and the fields they relate to, and the data they represent. For
example, what if there are multiple authors? If there were a place for
the additional biographical information URL in the 100 or 700 tags,
there would be no doubt which author is represented by the linked
information.
Geoff
--
Geoff Sinclair
Manager of Technical Services
Education Centre Library, Nipissing University / Canadore College
Tel: 705-474-3450 x4439
E-mail: geoffs_at_nipissingu.ca
Web: http://www.eclibrary.ca
Shirley Lincicum wrote:
> These links have always bugged me, too. Why doesn't LC just put this
> information into the MARC records where it would be more useful,
> searchable, etc. I suspect it has to do with lack of software tools to
> help them move the data into a MARC record efficiently. Does anyone
> know for sure? Not to rant, but it just drives me crazy when people
> assert that catalogers don't want to re-use data/metadata. Many of us
> do, we just lack the tools needed to make this happen, and most
> work-a-day catalogers have neither the time nor the skills to develop
> software. Some catalogers who used to have tools for developing macros
> and such to support their work have seen these tools disappear as we
> are forced into GUI interfaces ...
>
> Shirley
>
> Shirley Lincicum
> Collection Management Librarian
> Western Oregon University
> Monmouth, OR 97361
> lincics_at_wou.edu
>
> On Wed, Jun 11, 2008 at 8:12 AM, Frances Dean McNamara
> <fdmcnama_at_uchicago.edu> wrote:
>
>> There is one thing that might bear examination by this group. In it's reply to the report LC mentions the TOC, summary and other enhanced information that they put up on the web and link to via 856 fields in their MARC records. This must be costing them some effort to do. Yet we have found those fields to be problematic and nowhere near as useful as the Syndetics Enhanced content that we subscribe to. In fact, we now routinely delete those fields because they were causing problems.
>>
>> For instance:
>>
>> http://www.loc.gov/catdir/enhancements/fy0803/2007043803-d.html
>>
>> How useful are these links, really? Don't get me wrong, I think LC does lots of great stuff for libraries but I wonder if the time and effort putting up these web pages is worth it. They also do some biographical info and some Table of Contents. But they seem so crude compared to Amazon, Google, other enhanced content, and they seem to duplicate information you can find in those other places. Or here's a table of contents:
>>
>> http://www.loc.gov/catdir/enhancements/fy0730/2006047266-t.html
>>
>> Is this process whereby LC makes these web pages a manual duplication of other processes that pull this information and make it available?
>>
>
>
Received on Wed Jun 11 2008 - 15:43:51 EDT