Quoting "Brenndorfer, Thomas" <tbrenndor...@library.guelph.on.ca>:
There is an interesting document produced by Tom Delsey in 2007
about encoding RDA data. This was written before the DCMI-RDA
registered elements and vocabulary work, which is referred to as a
future endeavour:
http://www.rda-jsc.org/docs/5editor3.pdf
Yes, this is the document I alluded to in my post. I suspect it is not
up to date, but it is a starting point.
Of interest are the points about mapping controlled RDA values to
variable fields in MARC, or to fixed field values. There is a
suggestion that supplying both values might be a possibility in
properly designed data entry software. It may not lead to redundancy
since entering an RDA value (say from a drop down list) might
trigger a corresponding entry of something like an equivalent fixed
field code.
EXACTLY! In addition, if you look where code lists are used in RDA,
all of them allow for selection from the list OR creation of a new
term. There are various ways that this could be done. In MARC, the
code "other" is used in the fixed field, and something textual may (or
may not) be given in the variable fields. This is necessary because
MARC fixed fields are ... well, fixed in length, as well as being a
finite set of values. In another data format you could have a choice
of either a term from a list or to provide a different term, and these
could "live" in the same data element (because the value from the
list would have an identifier and the provided value would be just a
string of text).
Since we exchange data, however, you would want to add new values to
the authority list as soon as they proved useful so that everyone
could be using the same value for something new. In the Open Metadata
Registry, where the RDA lists are stored, you can add a new value as
"provisional" (or some other status to indicate that it's not on the
official list yet), and through some community action provisional
terms would be promoted to official status.
My ideal scenario for this is that new text values would be gathered
up automatically, either in individual systems or at the point of
sharing, and would be submitted for review to whoever is the assigned
maintenance agency for the particular list of terms. In this way,
music terms would go to the group assigned by the music cataloging
community, terms relating to films would be the responsibility of a
group assigned by the film cataloging community, etc. These lists of
terms could be managed independently, and since the lists are online
and encoded in standard formats, they could be retrieved on a regular
basis into library systems, and one could choose whether to use
provisional terms or only official terms in a cataloging system.
These ideas I think could lead to simplified data entry software by
following RDA's element-by-element approach. Entering a value (by
variable text for transcribed data or by a drop-down value or by a
search for an indexed term) could be followed by an option to supply
an associated fixed field code or normalized form (or have it
generated automatically). Added to this could be a field for the
relevant notes elaborating on the choice of data for the element.
Links to associated fields could follow. A display preview for each
element could be useful where we can see how the machine is
supplying our leading or trailing punctuation. On-the-fly proofing
and data verification could be made easier to implement since we
would be entering all data related to the element at the same time
in the same area on the screen.
Absolutely. In fact, in a document that I prepared some years ago on
how to transition MARC to a new format, one of the things I felt we
would want in a new format was to have the coded data and the display
data closer together, if not in the record itself at least on the
input screen. And if the display form can be generated from the coded
form there is no reason why a cataloger should be inputting both
(which is also a possible source of error). I suspect that the order
of creatingMARC records is that the variable fields are created
first, followed by (some) encoding of fixed fields. This scenario
might reverse that order, and would automatically fill in displays
where possible.
I don't know about you, Thomas, but this seems so obvious to me that I
rather marvel that we haven't gone in this direction already.
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
