While acknowledging the enormous
difficulty of this translation, I'd like to add a +1 to what Karen
wrote (I was starting to write the same thing :)). And I'm sure
Karen meant this as well but just to be more explicit, we need to
make sure that the intention and meaning we had originally is
still valid, that there is no better way of expressing that intent
currently, and that we use the the most appropriate way of
expressing that intent in the new language.
As a means of communication, BibFrame will need to find a way of
recording the intentions of various communities and sometimes
those subtleties make less sense outside of that context. For
instance, the distinction between bf:title and bf:titleStatement.
To me, a bf:title can be almost anything, taken from any part of a
resource or even made up by the person creating the data because
there wasn't a title. Some cataloging rules require that you use
a transcribed title from a clearly defined place in the resource
(that's what the bf:titleStatement is for). To a cataloger, this
is a valid distinction. Without questioning the validity of
making such a distinction (at least not yet :)), what is the
clearest most appropriate way of making this distinction?
On 7/25/2014 10:09 AM, Karen Coyle wrote:
[log in to unmask]" type="cite">
Straight translations from MARC to [anything else] don't make
sense unless you analyze not just the MARC coding but the
intention and meaning behind the data element. (I covered this is
in a code4lib journal article, to some extent.) That some bit
of data was broken up in a certain way in MARC is not necessarily
meaningful in other situations. Title is a good example, and
Thomale shows how hard it is to make sense based on MARC
subfields. One other example is personal author: the x00 field
has a dozen or more subfields to encoding personal author data. In
other MARC fields, all of that information is placed in a single
subfield (because of the limit of 26 data subfields per tag).
Milton W. $q(Milton Wheaton), $d1901-
Milton W. (Milton Wheaton), 1901-
Yet one of the biggest problems in translating MARC to [anything
else] is that because the data has only been expressed as text
strings, no consistency checking has been done on the content.
That 245 $p could have anything at all in it, including Aunt
Martha's apple pie recipe.
Developing a future format based on this data is a formula for
failure, I'm afraid. Yes, we will need to translate our old data
to some new form, but that is not the same as developing a new
format intended to mimic the data of old one.
"MARC21 as Data: A Start"
"Interpreting MARC: Where's the Bibliographic Data?"
On 7/25/14, 9:30 AM, Robert Sanderson
[log in to unmask]"
+1 to all of these :) And to add:
Do we need a title resource at all, or is a string
[log in to unmask] http://kcoyle.net
Philip E. Schreur
Head, Metadata Department