On 8/21/07, Karen Coyle <kcoyle_at_kcoyle.net> wrote:
I think that if we were to re-design our data with
systems in mind, rather than basing our data on the cataloging rules,
then we could greatly improve the catalog itself.
In essence, we've broken one of the very basic rules of systems design:
you are supposed to decide first what you want your system to do and
what outputs you want *before* you design your input record. We had the
input record long before there were systems, and we're still trying to
hobble along with an inappropriate data structure.
This comment really resonated with me.
Many catalogers feel (justifiably, I think) that our catalog interfaces
not infrequently make a hash of our data or fail to use it the way it
was intended to be used because the system creators do not read or do
not understand the implications of the cataloging rules and
documentation. To take a small example, when I started here 7 years ago,
the language limiter based on the MARC language codes that our ILS
offered, was hard-coded to over-retrieve--you got not only everything
that is in Japanese, but most of the things that ever were in Japanese
all mushed together in one result set. People complained, and after a
while, they "fixed" that by offering the alternative of hard-coded
under-retrieval (i.e., only the first language listed, as if most
libraries have no bilingual materials, such as many mainstream DVDs).
People are still complaining...
However, as someone has already pointed out, Karen's comment is really
referring to a more general phenomenon and not the quirks of any given
system. I think there are really two things here.
One is that we have a fair amount of data that is not optimally
formulated for manipulation by computers. AACR2 and MARC were developed
in the card catalog era and many things have not been reevaluated (that
I can tell) for the automation era. To take a small example, why are
some additional titles in 245 for items that have no collective title
not subfielded as title information, but instead are put in with the
statement of responsibility? If we were creating cataloging from scratch
today, I think we would do a lot of things very differently in terms of
*how* we achieve our ends.
The second is that we could benefit from starting an analysis of our
data with the functionality that we want to achieve rather than the way
we have done things up until now. I have recently been involved with an
OLAC (Online Audiovisual Catalogers) group that has been looking at best
practice for and problems with MARC language coding for videos,
especially DVDs, from the point of view of what sort of language
information do we want to provide and what are people likely to want to
do with this information. It has been an interesting experience and we
have come to the conclusion that some of our current practices do not
result in what seems to us to be the most useful breakdown of
information. We also concluded that we currently have no standard way to
record the original language of a film or video despite evidence that
people are interested in being able to search or limit this way. This is
just one small, niche area, but our data is made up of the sum of lots
of small, niche areas, many of which could benefit from this sort of
function-based examination.
Kelley McGrath
kmcgrath_at_bsu.edu
Received on Thu Aug 23 2007 - 06:51:56 EDT