Karen Coyle schrieb:
>
> I have never seen a good analysis of the systems problems that one faces
> when working with MARC records. One of my bugaboos is the "unit record"
> model, which, among other things, requires that the entire record be
> replaced when any changes are made. This is incredibly inefficient from
> a systems point of view, ...
But that depends a whole lot on the system and the way it is optimized.
To envision a system that replaces only certain parts of records isn't
necessarily easier. Record sharing and exchange has to be based on
units of some sort, and what if not complete records?
> Because there was no concept of the value of the
> fixed data elements, these were applied in a rather haphazard fashion
> among participating libraries, rendering them virtually useless for data
> processing.
>
Had these been covered by the rules (AACR), we'd probably be better off
with them now. RDA might learn from that and specify things that ought
to be coded from the start, like what used to be GMD.
> When I look at the RDA process, I see us going down this same road: the
> cataloging rules will be determined without any concern about the end
> system use, ...
without much concern for coding and format actually, but the latest
draft for chapter 3/4 has tables to show where current MARC21 places
things the proposed rules prescribe.
> and then systems developers are expected to come along and
> make something out of this data that didn't get any systems design
> concepts built into it. In the IT world, this is the classic nightmare
> of the IT department getting specs written by the marketing department
> that basically describe their current hard-copy practices.
>
But doesn't Google work from a much less coherent base of given
material, the designers of which still mostly don't care at all about
structuring their stuff, let alone metadata, despite DC having been
around for 10 years? (And G. disregards it anyway, as you know.)
The big issue is probably not the rules at all but the fact that any
cataloging rules will always produce only a small amount of data per
document whereas search engines work from full document content.
So, to improve end user results, more meat will have to be put on
the RDA skeleton anyway. ToC, abstracts, reviews, ...
Reliability in known-item searching and FRBR collocation, OTOH, cannot
be had without a good code of rules along time-proven ideas. It is only
discovery searching that can profit from extra verbiage. But what is
the relative importance of discovery searching vs. the other functions?
Discussions here seem to indicate that discovery searching is the only
thing worth talking about, but it may be it is because everybody takes
the other functions for granted. (Google can't do them - so who needs
them?)
B.Eversberg
Received on Mon Apr 30 2007 - 03:47:24 EDT