Todd,
>I think what Bruce is getting at is that XML lets us separate data encoding
>from data presentation. This makes it a different animal from MARC, and
>there is good reason to rethink how cataloging rules are to interact with
>the data storage mechanism. In particular, cataloging rules proscribe data
>presentation, e.g., AACR2 *still* focuses on how to lay out a catalog card.
>The data encoding and presentation are not divorced, as they are in XML.
>Therefore, we should be cautious in how we allow cataloging rules to
>influence our encoding decisions.
I, too, prefer the separation of encoding from presentation. I just don't
think that we can use MODS to be an XML-based carrier for previously
created metadata that doesn't have that separation (i.e., MARC) unless we
allow that metadata to be translated to MODS with a minimum of re-coding.
Yes, some of the re-coding can be done algorithmically, but my experience
is that highly stringent rules end up not being followed. So you can put in
a code in MODS for "this date is just a guesstimate", but you still need to
expect to receive data that doesn't have that coding.
>Sticking to the date-encoding part of the conversation, I think it a
>disservice to allow something like the following:
>
><date>c. 1954</date>
><date>c1972</date>
>
>It's poor encoding, and it makes it difficult to use the date as a retrieval
>criterion. I argued this on the list back in May.
Well, in MARC that isn't the date that is used for retrieval. There is a
date fixed field that is used instead. And it has codes that modify it
(single date, range of dates, estimated date....). So the question is
whether we should be mapping MODS to the fixed field date, which is richer
in some ways, or should we be using the date that displays in the publisher
field? For citations, the fixed field date includes day-month-year, so it
might be a better source of date.
> But if "c. 1954" is acceptable in MODS, then that
>flexibility is shot. In the case of dates in particular, ISO dates, for
>example, can express ranges and different resolutions and additional
>attributes can add qualifications to the date. XML validators can check
>that the encoded data is, in fact, valid, and presentation to the user is a
>separble issue.
I do think we have to decide how prescriptive MODS will be in terms of the
content of its fields. This has been the Dublin Core dilemma from the very
beginning. If there is some community that codifies its dates as
"[1996?-2001]" and they want it to stay that way, do we allow it? I think
we should. My preference is always that there be fields that are pretty
loosely defined available for the metadata that is loosely defined, and
other more stringent fields for the metadata that is more structured. You
can't force structure on the metadata that just doesn't have it, but you
should provide elements for the structured metadata where it exists. The
main thing is that you want to know, positively, whether you have a
structured data element or one where all bets are off. If you only provide
data elements for structured metadata, then what you get is unstructured
metadata in data elements for structured metadata, and you've got yourself
a mess. I say: provide for various levels of metadata rigorousness, and
make it easy to find the right level for your metadata so that people code
their data elements honestly.
>Anyhow, XML allows use to separate data encoding from presentation. This is
>true for date, authors, whatever. Cataloging rules, specifically AACR2, do
>not allow for this. Attempts to support various cataloging rules should not
>cause us to throw away the benefits of this separation.
No, but in reality we have to support both, and we should support both.
----------------------------------------------
Karen Coyle [log in to unmask]
http://www.kcoyle.net
----------------------------------------------
|