Quoting "Myers, John F." <mye...@union.edu>:
Karen Coyle wrote:
Mac, can you give more info on 1) difficulties caused ...
--------------------------------------------------
As Mac subsequently replied, the use of relator terms can cause
havoc with the display and indexing in the ILS.
I agree that the codes appear to be the culprit, but when I read Mac's
reply what I saw were mainly problems caused by the flat record
structure of MARC. Having done systems design I can attest to the
difficulty of providing anything other than record views, which Mac
shows in his second example. I think I could illustrate this in a
series of diagrams, but can't do it justice in an email.
The attempt via FRBR to move to a more *relational* structure is a
good step toward making it possible to do what many catalogers would
like to see: the ability to have lists that mimic the book or card
catalog structure. There are reasons why doing this is extremely
inefficient when you have a flat record like MARC. It's not that ILS
developers haven't wanted to provide this type of display, but to do
so requires that either 1) we have extremely inefficient systems that
would either be very slow or require huge amounts of hardware to give
quick response or 2) we move to a different record format, one that
can take advantage of relational DB design.
In my presentations I often point to the Open Library design
(http://openlibrary.org) -- not because OL is perfect but because it
has a more flexible data structure and therefore you can have an
author view, a book view, a work view, a subject view, etc. They
couldn't have done this if they had accepted the limitations of MARC.
If RDA development results in a more flexible data format, ILSs will
have possibilities they have never had under MARC. MARC was designed
as the MARC-up of a document, the card, not as a database-friendly
format. If we hang on to MARC, we also hang onto its limitations as a
data processing format.
kc
Some relator terms were more common in card days and then fell out
of favor as the implementation of ILSes resulted in split files or
misrepresentations in the displays. The classic example was Ben
Franklin where, if memory serves, there were separate listings for
him as author, editor, and printer. (Or under Mac's
misrepresentation scenario, if the printer entry was indexed "first"
then all subsequent entries would listed under him as a printer.)
Consequently, my first library employer had a regular practice to
strip them out, much as Mac's clients request currently. Things
were substantially mitigated with the development of relator codes.
For whatever reason, ILSes seem more forgiving of them -- they do
not go into the display or indexing. In that regard, I would wish
that the relevant LCPS had been formulated conversely, to eschew
terms in favor of codes, despite the subtle non-compliance with RDA
as written. While my early experiences shaped my ability to live
without "illus.", "ed.", "comp.", etc., my subsequent work with
media taught me the value of "drt", "prd", "aus", etc.
What we need though is not to be tilting at the straw men of terms
and codes but to be fighting for systems that put the information we
provide to good use. The indexing and display should not be broken
up by the absence, presence, of difference of a term or code. But
the term or code should be leveraged by the system to facilitate
selection, presumably via a faceting function after execution of the
initial search.
John F. Myers, Catalog Librarian
Schaffer Library, Union College
807 Union St.
Schenectady NY 12308
518-388-6623
mye...@union.edu
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
