Karen Coyle <[log in to unmask]> wrote of Jeffrey's post:
>... we can lose some of the oddities of MARC that are making it hard
>to add new information to our record format.
Our experience is the same as Jeffrey's. Despite its "oddities".
we've found nothing to match MARC21 as a coding system for
bibliographic data. We can walk from MARC21 to any system a client
might want, including UKMARC*, but not back again. This says
something about the granularity and specificity of MARC21.
One of our staff members held a MARC seminar in Geneva for a group
attempting to generate a coding system for bibliographic data. They
were unaware they were reinventing the wheel, and were astounded that
such an excellent tool existed. Unfortunately some sales persons of US
ILS in Europe have told their clients that "no one uses fixed fields,
so just ignore them"; the resulting records can not be easily used
across systems.
Just as RDA fails to take full advantage of the received wisdom in
RDA, a fear a replacement coding system will not take full advantage of
the received wisdom of MARC.
Certainly there are MARC oddities to be removed, e.g. the variation of
the meaning of fixed field values for different genres, the departure
from optimum display order in field tagging (5XX and 33X as prime
examples), splitting of ISBD's material specific area among several
fields, redundancy between fixed and variable field data dating from
when variable fields were less accessible.
>For example, we do not have a way in MARC to associate an identifier
>with a particular set of subfields within a field.
This is not a need we have experienced, apart from the new 33X fields
in cataloguing a kit. The expressed need to associate a particular
added entry or subject heading with a particular portion of a resource
is met in MARC (6XX and 7XX $3), but is rarely used. The wealth of
possibilities in MARC have not been fully utilized, both in what could
be coded, and what use could be made in ILSs of information normally
coded.
>Although a $0 has been added to the MARC format so that it can accept
>some of the RDA ata, the subfield remains ambiguous in some fields,
>and therefore isn't usable in the intended way (substituting an
>identifier for a articular data element).
Coul this not be met by having the $0 follow the data the code
represents? While I am happy to *add* an identifier to a data
element, I hesitate to *substitute* an identifier for a data element
which is normally transcribed. I still remember the disaster which
was PRECIS.
Currently we find making controlled vocabulary data (classification
numbers, main, added, and subject entries) live links in our OPAC to
work just fine.
>We have fields that have used $a-$z and have nowhere to go. Should
>we have 2-character subfield xodes? That doesn't solve the problem
>of ordering which seems to plague some systems.
One difficulty with two letter subfield codes would be telling the
difference between a two letter code, and a one latter code followed
by a lower case data element, e.g., "e-Book". A one letter code with
punctuation might work better, e.g., 245 =$b and :$b.
While we support several ILS which can only display MARC fields in
number order, we have never encountered one which requires that
subfields be in alphabetical order. Since AACR2 changed the order of
subelements in a conference entry, bringing date earlier, ILSs have
had to cope with out of alphabetical order subfields. While
alphabetical order is a mnemonic advantage, and should be observed
(e.g., the complicated proposed 26X), the newer 246 and subfield coded
505 paid no attention to it. This is but one of several departures
from Ms Avram's vision.
I agree absolutely with Karen's emphasis on content, e.g., city *and*
jurisdiction in the imprint statement whether on resource or not.
__ __ J. McRee (Mac) Elrod ([log in to unmask])
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__________________________________________________________
*UKMARC differs from MARC21 in that ISBD punctuation is not included,
but is supplied by the system based on subfield coding. That means
that MARC21's :$b subtitle, =$b parallel title, and ,$b second title
in a collection without a collective title, must have differing
subfield codes. Which reminds me, it seems to me 260$c plus the
copyright sign work just as well to distinguish publication and
copyright years as the complex proposed new MARC imprint field.
|