Marc Truitt wrote:
> focus group attended by librarians from about 15 major ARL customers and
> the head of product development at the company whose the ILS we all
> used. One of our number mentioned that the system made very poor use of
> MARC fixed-length coded data elements for narrowing search results. The
> lead company representative then launched into a 10 minute diatribe, at
> the end of which she said "I can't imagine that *anyone* would want to
> limit by *that* [specific element]. How many in this room believe their
> institutions would find this functionality useful?"
>
> Thirteen hands went up.
>
Then again, I was often in the situation of trying to provide system
functionality based on fixed fields, but couldn't provide a reliable
user experience because the majority of the libraries in the system had
not filled in the fixed field in question. Therefore, using it to narrow
a search meant that the retrievals would not be accurate because they
would only be against the minority of records where the data had been
provided. My experience was that the only fixed fields that were
reasonably reliable were 008 date and language (and the Leader codes).
And look at what you have to do to make use of a fixed field like date
for retrieval or sorting. You have to figure out what to do with dates
like 19uu. You have to deal with records that have left the date blank
(the first date sort we did got three or more pages of blank dates
before we started getting real results). You have to decide what to do
with multiple dates, questionable dates, and reprint v. original dates.
If you talk to catalogers about the fixed fields, they will remind you
how much time it takes to fill them in, and why should they since
systems don't use them anyway? So we've got a chicken-and-egg problem.
The idea of the fixed fields was that they would be machine-processable.
Unfortunately they weren't designed (or cataloging systems weren't
designed) to make it easy enough for humans to provide the data in a
useful format, and provide it accurately. There are about 200 different
fixed field data elements (not counting the 006). Even if they were all
coded when appropriate, and coded accurately, I'm not sure how many
would provide useful services for catalog users. And if economics were
to dictate that you, a cataloger, could only fill in the 3, or 5, or 7
most important ones, how would you know which ones those are?
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Fri Mar 06 2009 - 18:04:07 EST