We are preparing for MODS version 3.1. The primary need is to incorporate
the changes in mods-for-mads.xsd so that MADS may reference MODS elements
instead of repeating them. There are several other changes that have been
discussed on this list or are small additions that we would like to
incorporate at this time.
These changes are generally additions or corrections and do not invalidate
existing MODS instances. Thus, an incremental version number.
We also have a list of more substantive changes that will affect existing
instances or require broader discussion. I will circulate these separately
as candidates for MODS 4.0.
Following are the changes with links to the MODS archives where there has
been previous discussion (I've included the messages with summaries of the
issues). Please review the previous messages if necessary, since we
probably don't want to have the same discussions again.
1. Implement the reorganization in mods-for-mads.xsd
Rationale: necessary for implementation of MADS, since it uses MODS
2. Change <coordinates> to not be required under <geographic>.
Rationale: This was an oversight/error.
3. Define <part> under <mods>, not just <relatedItem>. Take out
documentation (in MODS guidelines) restricting <relatedItem> to
4. Define <nameTitle> with subelements <name> and <title> as a top level
element. This would give the option to explicitly indicate a compound work
identifier, i.e. a uniform title entered under author to correspond with
1XX/240 or 700$a$t rather than a relatedItem subrecord.
(Rebecca Guenther, Feb. 28, 2005)
(Stephen Hearn, Mar. 2, 2005)
By including as a top level element of course <nameTitle> could also be
under <relatedItem> (which includes everything under <mods>). We see it
used at the top level when it is the compound identifier for the work
being described itself and under relatedItem when it's contained in the
5. Addition of attribute "objectPart" to <language> to indicate language
of what part of the resource described (to be distinguished from the lang
and xml:lang attributes, which refer to language of the value in the tag).
e.g. <language objectPart="summary" authority="iso639-2b">spa</language>
indicates that only the summary is in Spanish.
Rationale: there is no way to indicate that the language specified is for
something other than the entire text.
6. Add attribute "type" to dateOther to specify other kinds of dates. (Not
Rationale: Everyone has their favorite date type associated with specific
materials. MODS enumerates the most important ones as specified by users,
but could allow for extensibility for other types of dates by including
7. Changes for the emerging content standard Cataloging Cultural Objects:
7.1. add attribute "type" to <genre>
Rationale: to distinguish different aspects of genre: in CCO this includes
class, work type, style.
7.2. add attribute "type" to <form> under <physicalDescription>
Rationale: to be able to specify whether the form concerns materials or
techniques.e.g. type="material": oil paint; type="technique": painting
7.3. add attribute "type" to <physicalLocation> under <location>
Rationale: to indicate different kinds of locations, e.g. current,
discovery, former, creation
8. Allow for empty elements for xlinked elements.
Rationale: xlink is an attribute, so the element with which it's
associated may be empty if only a link and no text is needed.
9. Add displayLabel attribute in <classification>.
Rationale: corresponds to MARC 050$3 (materials specified).
This is needed for instance for mapping to LC's American Memory
We are working on incorporating these changes into the schema.
^^ Rebecca S. Guenther ^^
^^ Senior Networking and Standards Specialist ^^
^^ Network Development and MARC Standards Office ^^
^^ 1st and Independence Ave. SE ^^
^^ Library of Congress ^^
^^ Washington, DC 20540-4402 ^^
^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^
^^ [log in to unmask] ^^