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.
 http://journal.code4lib.org/articles/5468 "MARC21 as Data: A
 http://journal.code4lib.org/articles/3832 "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