Bernard,
I beg your pardon, but UKMARC is far from defunct!
We are still using it here at the British Library and supplying catalogue
records to our customers in UKMARC format.
I have watched this discussion regarding the use of XML instead of MARC
with interest and it is my opinion that the urgency to replace MARC with
XML has not been prompted by the limitations of MARC formats in general,
but by the limitations of MARC21 specifically (Oh my, I think I just kicked
the Holy Grail!). The coding, or lack of it, in the 245 field, arguably
the most important field in a record, makes it particularly difficult to
manipulate the data within it, and fiendishly difficult to convert between
MARC 21 and any other MARC format be it UKMARC or UNIMARC.
Let me give you some examples. In a MARC 21 record the only way of
distinguishing between a subtitle, a parallel title and an additional title
is by looking at the punctuation which precedes the subfield code 'b'
(which I will in future refer to as $b). This is not repeatable, so
further instances of 'other title information' are separated and
distinguishable from each other by punctation alone. I can see how this
would be difficult to manipulate in a database situation.
In UKMARC, first of all we have no embeded punctuation. Second, we have a
different subfield code for each of these types of title information; $b
precedes a subtitle, $k precedes a parallel title, $i precedes an
additional title by the same author and $j precedes a title by another
author(. Futhermore, all of these subfield codes are repeatable.
Another problem in MARC21 is that once you have a $c in the 245 no further
subfield codes are allowed, so statements of authorship and any futher
title information are separated and distinguished from each other by marks
of punctuation. Again, not much use in a database.
In UKMARC, we have no such restrictions. Each statement of authorship is
preceded by $e and any other title information required may be preceded by
its appropriate subfield code, in whatever order is required to provide a
true record.
In a personal author heading in MARC21 even the family name and first name
are placed within the same subfield, whereas in UKMARC the two are placed
in separate subfields ($a and $h).
I would be the first to admit that UKMARC does not have the same rich range
of fields and subfields that MARC21 has, but that is easily remedied and I
believe that in certain areas it is a superior format. Part of my job is to
write rules for converting records between MARC formats and for converting
between non-MARC to MARC. Even though UNIMARC uses completely different
field tags and subfields, it is much easier to convert between UNIMARC and
UKMARC than it is to convert between UKMARC and MARC21. This is because,
like UKMARC, UNIMARC places each part of the record in a separate subfield
and embeded punctuation is not required. Using off-the-shelf applications
(Data Magician and USEMARCON) I have also found that it is easier to
convert comma delimited records into UKMARC and then use MARC conversion
software to convert to MARC21 rather than try to convert from comma
delimited to MARC21.
In the not too distant future, it seems likely that UKMARC will be killed
off by simple market forces. The number of USMARC/MARC21 records 'out
there' far exceeds the number of UKMARC records. Most library systems
suppliers are American and fewer and fewer are prepared to support the
UKMARC format, to say nothing of Z39.50 implications.
We UKMARC users have been castigated for not embracing MARC harmonisation
more enthusiastically. I believe this means that we have not been prepared
to to make UKMARC a lot more like USMARC, since, as far as I am aware, the
USMARC community was not prepared to adopt any UKMARC practices, however
sensible. Now it seems that the death knell is ringing for MARC itself
because of the limitations of MARC21 alone.
Brenda Young
NBS Research and Development
The British Library
***The opinions expressed here are entirely my own and do not necessarily
represent the views of the British Library.***
______________________________ Reply Separator
_________________________________
Subject: Why not UNIMARC?
Author: Bernhard Eversberg <[log in to unmask]> at Internet
Date: 19/04/2000 18:06
What are the opinions on UNIMARC?
It is presumably more modern, and has been developed with a keen eye on
international exchange and interoperability. I just wonder why it is
never mentioned in this list. And before setting out to invent yet another
wheel, why not look at wheels newer than MARC that are already there.
And it lacks some of the glaring misfeatures of USMARC.
USMARC's first purpose was catalog card production, and this can still
be seen as a very pervasive feature in the architecture, and MARC21 hasn't
changed that much, or has it? Cornels Zeeman forgot to mention the nasty
fact that USMARC even still preserves the punctuation *in addition to* the
subfield codes. (Programmers back in the 60s, because of this, needed only
to strip out the subfield codes and had the whole text string for the card
ready for line breaking. Now try to do that more efficiently with XML! But
it *is* atrocious, of course.) UNIMARC (and the now defunct UKMARC) do not
share this.
Let this be enough for today,
best wishes, B.E.
Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, D-38023 Braunschweig, Germany
Tel. +49 531 391-5026 , -5011 , FAX -5836 e-mail [log in to unmask]
|