Karen keeps asking this question about what MODS is for and I'll try again
to answer it.
One incentive for developing it was that people were asking for an element
set that uses XML, that is compatible with library data, and that uses
language based, rather than numeric tags. We also were particularly
concerned about the description of electronic resources.
Some of the uses that we pinpointed have been initiatives that require a
bibliographic record output in XML that is simpler than full MARC but not
as simple as Dublin Core. Some of these include the Open Archives
Initiative Harvesting project, Z39.50 Next Generation (SRU and SRW), and
METS. The descriptive metadata for each of these needs to be in XML. OAI
allowed for output as Dublin Core simple or full MARCXML; ZING in Dublin
Core, MARCXML and ONIX; METS had endorsed Dublin Core and MARCXML. In all
of these initiatives needs had been expressed for something richer than
Dublin Core (since converting data from MARC to DC necessarily drops a lot
of data) but less rich than full MARC as expressed in MARCXML (because of
the less user-friendly nature of numeric tags, fixed field data and the
larger number of data elements). Now all of these have the MODS
alternative: LC is exposing its records on the OAI server in MODS as well
as Dublin Core and MARCXML, and both ZING and METS have endorsed MODS as a
descriptive metadata format. It is particularly useful for something like
METS, which was developed for complex digital library objects which
require more complex descriptions than a simple descriptive schema can
offer and because of the necessity to detail relationships between parts
of digital objects.
But along the way we have heard from others who want to use MODS in other
ways, such as what Karen mentions, where there are varieties of metadata
creation (or library cataloging) that have similarities but still some
differences. There are a few projects that bring together metadata from
library catalogs and university presses that fall in this category. In
addition there seems to be some interest in using MODS for original
cataloging, again because it's richer than something simple like Dublin
Core but easier to use because of the language-based tags and fewer data
elements and it is more compatible with what is in library catalogs.
Quite awhile ago Karen asked this same question on this list, and Robin
Wendler gave what an interesting response (from 12 June 2002 in the MODS
archives):
"I thought MODS was intended to be a lightweight way of representing
metadata that is basically bibliographic in XML, and of providing
semantics that are a more natural fit in a library environment than those
of Dublin Core elements. But I could be wrong. ;)
I did not necessarily see a bias toward conversion from existing MARC
vs. initial creation in MODS. Nor did I see it as the Holy Grail successor
to MARC. I think that the true successor to MARC will only be developed
from rigorous analysis (as Tom Delsey has done for LC) of the current
format and an extensive community process. Given the huge volume and great
complexity of data flow in our community AND the current focus on how to
implement FRBR, it will take time to get this right. I guess I was
thinking that MARCXML and MODS between them would tide us over until that
happy day. "
Since we put MODS out we have had interest from various groups, not all
traditional libraries. There were specific purposes that we had in mind
when we started this, but we thought it may satisfy some needs we hadn't
thought of. Maybe we're trying to be too many things to too many people
and don't have a clear enough vision, but it does seem to be something
that is generating some interest perhaps because of its flexibility.
Rebecca
On Tue, 3 Dec 2002, Karen Coyle wrote:
> Randy,
>
> I suspect that part of our "groping in the dark" here has to do with the
> fact that we haven't really settled on what the purpose of MODS is. I also
> think that it isn't the richness of MARC that people object to, it's the
> parts of it that are detailed but not useful.
>
> MARC and MODS are just data structures. What should be determining those
> structures is the data that we intend to carry. There's a big difference if
> we are carrying data that results from library cataloging, or if we are
> carrying data that has some other origins. Library cataloging data will
> have a certain level of detail, some amount of which is deemed useful in
> our environment. If instead MODS will be used to carry data that, for
> example, originates in the HTML of bookstore pages, then it will have less
> of that richness and the data structure will not need some of the features
> of the library cataloging record.
>
> What I am beginning to see here, mainly arising out of the postings by Yves
> (thank you, Yves!), is that MODS may be a good format to unite varieties of
> library cataloging that have considerable similarities but enough
> differences that they cannot reside in the same systems. It may also be
> able to carry bibliographic data that is somewhat less rich than library
> cataloging but considerably more rich than something like Dublin Core. For
> the moment, however, I think we will achieve more if we have a clear goal
> for MODS (i.e. carrier for library cataloging) than if we simply throw it
> out there and say "whatever."
>
> ----------------------------------------------
> Karen Coyle [log in to unmask]
> http://www.kcoyle.net
>
> ----------------------------------------------
>
|