I've got to stop making Karen carry the whole load...
At 10:35 PM 7/29/2003 -0400, you wrote:
>My worry is that if people on this list don't take this issue more
>seriously, MODS data will end up much more limited than it ought to be.
>I just realized the other day that the arguments I've been making on
>this list amount to arguments about proper XML practice, and have
>little to do with bibliographic data per se. Yet virtually every time
>I'm met with the sense that there is something sacred in AACR2. I
>think these rules need a major rethink for the XML world.
I'm not sure that you are arguing for proper XML practice. XML legally and
legitimately permits a tremendously wide range of data designs. Which one
in a given instance depends on the content of your data, the functions you
to fulfill, and the constraints you must work within. I would argue that
much of what
you've been proposing falls into the realm of content rules. Metadata
proper XML practice, no.
Different principles govern the design of a metadata scheme that is
intended to carry legacy
metadata than those that apply when metadata will exclusively be created
directly in the scheme.
"Native" metadata schemes can be extremely granular, rigorous, and
prescriptive, but schemes
that have to accommodate legacy metadata must do just that: accommodate it.
If you believe
that even everyone who *can* write God's own parser will do so, you will
live with disappointment.
;-) People will put loosely formatted data in MODS fields because that may
be all they have and
they lack either the resources or the willingness to write elaborate parsers.
>Again, I realize practical considerations matter, but they shouldn't
>hamper the MODS design. So, I really think we need a simple qualifier
>attribute that can cover dates and names. Oh, and it'd be nice if we
>could at some point come back to the subject of quotes and so forth in
My understanding has always been that MODS was not intended to be the last
on bibliographic metadata in XML. It was deliberately not designed de novo.
intended as a bridge between the data encoding used by libraries for
hundreds of millions
of records since the 1960s and current information technology. As such,
considerations *must* "hamper" (or at least inform) MODS design.
'm with Karen: enhance MODS to permit highly structured data where it truly
matters, but enable
people to supply the sloppy metadata they have in fields designed for that
purpose. Robin's corollary:
Do not bend over backwards to allow precise structures everywhere, because
that will violate what was
supposed to be a principle of MODS: ease of use, low barriers to use (even
As the ancient Greeks believed, moderation in all things.
We can wrestle about quotes later...
Harvard University Library
Office for Information Systems
1280 Massachusetts Ave., Suite 404
Cambridge, MA 02138 USA
[log in to unmask]