Jonathan Rochkind wrote:
>
> The problem needs to be attacked from all angles at once, with all of us
> cooperating. It is not sufficient to blame MARC for being bad, or to
> blame systems for not taking full advantage of MARC. We've got to do it
> all together. As I've said before, I firmly believe that the disciplines
> of cataloging, metadata, and systems design are converging into
> something that must be treated as one unified discipline, not segmented.
>
Absolutely. I look to our recent history to understand why we have this
vast division between cataloging and systems development. (I think we've
been down this path before, here on NGC4LIB, so some of this may be a
repetition.) In the card catalog days, cataloging and the development of
the catalog were one and the same: cataloging created the catalog card
entry. We took that entry and made it machine-readable (in the 1960's)
in order to produce the cards more efficiently. The development of the
OPAC, however, did not come from the catalog department, and it wasn't
directly informed by cataloging. At that point, cataloging and the
creation of the catalog diverged.
Having been on the ground in 1980 when we first developed the MELVYL
catalog at UC, we basically saw our task as taking the data we had (MARC
records that had been produced as a side product of the libraries' use
of OCLC to print cards) and making it searchable. There was no concept
that perhaps the data should need to change. We really were creating the
online "card catalog" to some extent. There never was the possibility of
going back to the catalog department and asking for different data. That
would have been unthinkable. We were a kind of clean-up crew, recyclers
of the libraries' canonical data. It was fun to find new ways to make
use of that data and we often felt very clever, but we were unmistakably
the last step in a process over which we had no influence.
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, and I know that our system was basically in
constant churn, re-indexing incoming updates at a furious pace. Yes,
there were things to do to mitigate that, but still it needs re-design.
Then there are the problems of redundancy within and between records,
and of inconsistency (when the same data is entered differently in
different fields). 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.
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, 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.
OK, enough complaining. I'm going to start setting down some of the
requirements for a new data record. I think there has been a beginning
on futurelib, but we really need to put forth the systems needs in a
clear, coherent fashion.
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Fri Apr 27 2007 - 08:49:47 EDT