The Library of Congress » Standards » MODS Official Web Site
Metadata Object Description Schema: Official Web Site
HOME >> Changes for MODS Version 3.4

Changes for MODS Version 3.4

The following changes for MODS Version 3.4 have been approved by the MODS Editorial Committee. Version 3.4 will be backwards compatible to 3.3 and therefore only be able to introduce certain types of changes that do not result in invalidating existing MODS records. The Committee may also consider major changes for a Version 4.0 at a later date, which would not be backwards compatible. This would offer the opportunity to make some structural and otherwise significant changes, such as greater use of externally-defined vocabularies and properties. These will be documented on the MODS site when the information is available. Changes listed below include the date approved by the MODS Editorial Committee.

Functional changes

  • Bind a specific name to a title to create a Uniform title. A new attribute, "nameTitleGroup" will be added to both <titleInfo> and <name>. The data type of this attribute will be string. To link a title and a name, MODS implementers will add the same value to @nameTitleGroup on the relevant <titleInfo> and <name> elements. (December 8, 2009)
  • Add attribute "usage" with the value "primary" to the following MODS elements to indicate which or repeated elements are most important: titleInfo, name, typeOfResource, language, subject, classification, genre (December 8, 2009)
  • Link translations and transliterations through a shared attribute. Each MODS top-level element will now have a new attribute, @altRepGroup.(October 27, 2009)
  • Add attribute "shareable" with one value "no" to the following elements: tableOfContents, abstract. This will mark data as proprietary that can only be used locally. (June 10, 2009)
  • Add lang, xml:lang, script and transliteration attributes to all textual MODS elements: This will introduce more flexibility for adding specific elements to a MODS record using multiple languages. (March 25, 2009)
  • Add the "displayLabel" attribute to all top-level MODS elements that now lack it. Rationale: makes MODS overall more consistent, and promotes easier use of MODS as a back-end format for customized cataloging and discovery systems. (March 11, 2009)

RDA-related changes

  • Add authorityURI and valueURI attributes to elements that have authority attribute (October 14, 2009)
  • Add authorityURI and valueURI attributes to subject subelements (October 14, 2009)
  • Add value "family" to the attribute "type" under mods:name to indicate that the named entity is a family (August 11, 2009)
  • Add values "single unit ", "multipart monograph", "serial", "integrating resource" as enumerated values for mods:issuance. The more general "monographic" and "continuing" will be kept if such distinctions are not needed. (June 10, 2009)
  • Define <scriptTerm> under <language>: a new subelement of <language> will be introduced, <scriptTerm>, with attributes type (code, text) and authority. This will allow explicit and standardized indication (using iso15924) of the script used in a resource. (March 25, 2009)

General/structural changes

  • Enumerate the MODS version attribute to allow for specific indication of the particular MODS schema version used in the instance (currently the schema only includes the value "3.4" but will now also allow for "3.0", "3.1", "3.2", "3.3".) (July 28, 2009)
  • Add <physicalDescription><extent> as a global element to the MODS namespace but not <part><extent>. It is not possible in version 3.4 to harmonize the definitions, since <extent> in these two places is very different, and changing either of them is too big a change for a minor release version. The short term-solution for MODS 3.4 is to only put physicalDescription/extent into the MODS namespace and not part/extent. In MODS 4.0 the definitions will be harmonized or one of these elements renamed so that both can be in the MODS namespace. (March 25, 2009)
  • Reorganize the schema to externalize all elements and definitions and make the schema easier to read. (Jan.14, 2009)
  • Define explicitly all elements in the MODS namespace (i.e. as "global" elements) so that they are addressable individually to other schemas and information systems. This requires the definitions of elements with the same name to have the same definition. (Jan. 14, 2009)

Consistency changes

  • Add the following attributes to location/holdingSimple/copyInformation/note: "ID", "lang", "script", "transliteration", "xlink", and "xml:lang". Rationale: adding these attributes will harmonize the definition of <note> with the other places this element appears in MODS. (March 11, 2009)
  • Add the "type" attribute to location/holdingSimple/copyInformation/form. Rationale: adding this attributes will harmonize the definition of <form> with its definition within <physicalDescription>. (March 11, 2009)

Miscellaneous changes

  • Add value "edtf" to the attribute "encoding" under originInfo dates. This indicates use of the Extended Date Time Format. (June 17, 2009). Also add value "temper" to the attribute "encoding" under originInfo dates. This indicates use of the TEMPER format (August 11, 2009)
  • Add attribute "supplied" with a single value "yes" to these elements: originInfo/edition, originInfo/place, originInfo/publisher, physicalDescription/extent, and titleInfo. This will mark data as having come from an outside source and that it is possibly questionable. (Possible changes to the "qualifier" attribute on dates may be forthcoming in a later version for consistency.) (June 10, 2009)
  • Add values "references" and "review of" to relatedItem attribute "type". Mechanisms for extending the list of relatedItem types will be considered for MODS version 4.0. (April 8, 2009)
HOME >> Changes for MODS Version 3.4

Questions and comments:
 Contact Us ( October 18, 2010 )
Legal | External Link Disclaimer