The Library of Congress >> Standards >> MODS
Metadata Object Description Schema: Official Web Site

HOME >> Guidance >> User Guidelines Version 3 >> Introduction

MODS User Guidelines Version 3

Introduction and Implementation


This document should be used in conjunction with the Metadata Object Description Schema (MODS) mappings (MARC to MODS and MODS to MARC) and Outline of Elements, as well as additional information that can be found on the MODS website. MODS is an XML schema for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications. It is a derivative of the MARC 21 bibliographic format (MAchine-Readable Cataloging) and as such includes a subset of MARC fields, using language-based tags rather than numeric ones. The guidelines are primarily intended to be used for assistance in creating original MODS records, although they may also be instructive in interpreting MODS records that have been converted from MARC 21 or for use in developing detailed conversion specifications. This document has been revised to reflect MODS version 3.3.

Definitions (semantics) of MODS elements may be found in the equivalent element definitions in the MARC 21 Format for Bibliographic Data where they have not been explicitly given in these guidelines. The MODS to MARC mappings show equivalent elements. These guidelines do not reproduce definitions from MARC 21, but attempt to complement them in giving particular MODS usage. The elements in this document are given in the order of the MODS schema itself.

XML Structures

MODS is expressed using the XML (Extensible Markup Language) schema language of the World Wide Web Consortium. XML provides markup for documents and is expected to allow more flexibility and detail than HTML (Hypertext Markup Language). It serves well as a syntax for metadata.

By using the XML schema language, MODS defines main elements, child elements (i.e. subelements), and attributes of elements and subelements. Content of elements are included in the lowest level elements so as to avoid "mixed content", which is when some elements contain character data interspersed with child elements. For instance, if <titleInfo> contains subelements for <title>, <partNumber>, <partName>, then <titleInfo> is only a wrapper tag to include the more specific elements <title>, <partNumber>, <partName> and does not contain any character data. (A "wrapper" tag is one that it used only as an element that binds together child elements, but contains no data other than tags.)

Attributes may be associated with elements at any level and are defined with the element with which they are associated. They serve to modify the element. Common attributes that occur throughout the schema are: type, encoding, and authority.

A MODS document contains a schema declaration that indicates the MODS namespace. Within a record or group of records it is optional to use the "mods" prefix before each element (and before the "mods" namespace declaration), since the MODS namespace is indicated in the record. It is most useful to use the prefix "mods:" before each element when combining a MODS record with XML data from another namespace, e.g. a MODS record within a METS document.

The schema declaration for MODS Version 3 is:

<mods xmlns:mods=""> with filename mods-3-3.xsd.

or if using "mods" as a prefix to each element:

<mods: mods xmnls:mods=""> with filename mods-3-3.xsd.

An "XSLT stylesheet" (Extensible Stylesheet Language Tranformation) may be written to transform the MODS data in some way for output. Examples include using a stylesheet to place the record into a template with easy-to-understand element names in XML; using a stylesheet to formulate a display that looks like a catalog card; using a stylesheet to transform coded data into textual form.

Implementation Notes

Cataloging rules. Any set of cataloging rules may be used with MODS, as is the case with MARC 21.

Punctuation. If using International Standard Bibliographic Description (ISBD) punctuation in creating MODS records, punctuation should be retained if it occurs within an element, but should be dropped between elements. If desired, an XSLT stylesheet may be used to generate an ISBD display from the MODS elements and data.


  <placeTerm type="code" authority="marccountry">nyu</placeTerm>
  <placeTerm type="text">Ithaca, NY</placeTerm>
  <publisher>Cornell University Press</publisher>

Display after XSLT transformation

  Ithaca, NY : Cornell University Press, c1999.
  [The comma between "Ithaca" and "NY" and between "press" and "c1999" is generated by the XSLT stylesheet on the basis of the coding.]

Relationship between MODS and MARC 21 elements. Most MODS elements have equivalent ones in MARC 21, although there are a few that do not exist in MARC 21 because they were felt to be particularly important for digital resources, a particular target for MODS. An example is <digitalOrigin> under <physicalDescription>. The Library of Congress will attempt to keep the two element sets in sync as much as possible.

Elements with no mapping. When using the MARCXML to MODS stylesheet, elements not in the mapping will be dropped. Some elements will be mapped to a more general one in MODS if several MARC 21 fields are mapped to the same MODS element as repeated elements (e.g. 130, 240, 730 all mapped to <title type="uniform">). It is expected that records converted from MARC to MODS that are then converted back to MARC will lose some data or specificity of tagging.

Order of Elements. Note that the order of elements in the MODS schema does not assume display order. A stylesheet is used to control display order of MODS records.

Element repeatability. All MODS top-level elements are repeatable.

MODS record identifier. It is expected that a MODS record would have its own unique ID in addition to any other identifiers associated with the resource and indicated under <identifier>. The MODS record identifier is indicated in <recordInfo><recordIdentifier>.

Root elements. All top-level MODS elements (those immediately subordinate to <MODS>) are declared as global. Thus, they may be root elements for instance documents, or imported into other schemas. Future work includes specifying some elements at subsequent levels as global.

Mandatory elements. No element is mandatory in a MODS record, however, every MODS record requires at least one element. Applications may wish to develop profiles specifying mandatory elements as needed.

HOME >> Guidance >> User Guidelines Version 3 >> Introduction

MODS (icon) Questions and comments:
Contact Us ( July 28, 2009 )