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

Description of MODS 3.4 Changes

June 2010

The following summarizes the changes for MODS Version 3.4 that were approved by the MODS Editorial Committee and are codified in the MODS 3.4 schema announced on June 10, 2010.

Primary changes

The first two additions to MODS help to accommodate bibliographic practices that have been common in many libraries with AACR and prior cataloging rule environments: name/uniform title combinations and "main entries". Others enable identification of the primary topics for a resource and enable linking and identifying translations and transliterations in our increasingly multilingual environment. These new features have been requested by users.

1) Explicit linking for names and uniform titles

The MODS schema 3.4 defines an attribute @nameTitleGroup that can be used with <name> and <titleInfo> to enable an explicit link between a name and a title when that is desirable. The same value is assigned to this attribute for the two elements. This attribute is used to link names to uniform titles when the name-uniform title combination is an authority controlled heading.

EX - There are multiple names and only one is associated with a title.

<titleInfo>
     <title>Beethoven's Emperor concerto, lecture recital</title>
</titleInfo>
<titleInfo type="uniform" nameTitleGroup="1">
     <title>Concertos, piano, orchestra, no. 5, op. 73, Eÿ major</title> </titleInfo>
<name type="personal" nameTitleGroup="1">
     <namePart>Beethoven, Ludwig van</namePart>
     <namePart type="date">1770-1827</namePart>
</name>
<name type="personal">
     <namePart>Sharpe, David</namePart>
     <role>
          <roleTerm type="code" authority="marcrelator">prf</roleTerm>
     </role>
</name>
<name type="personal">
     <namePart>Cicconi, Christopher</namePart>
     <role>
          <roleTerm type="code" authority="marcrelator">prf</roleTerm>
     </role>
</name>

EX - The same name is part of more than one name-title heading in a record. For instance, the resource contains two components with different titles (and no collective title) but the same author: Adventures of Tom Sawyer by Mark Twain and Adventures of Huckleberry Finn by Mark Twain.

<name type="personal" nameTitleGroup="1">
     <namePart>Twain, Mark</namePart>
     <namePart type="date">1835-1910</namePart>
</name>
<titleInfo type="uniform" nameTitleGroup="1">
     <title>Adventures of Tom Sawyer</title>
</titleInfo>
<titleInfo type="uniform" nameTitleGroup="1">
     <title>Adventures of Huckleberry Finn</title>
</titleInfo>

Note: Name-title headings that are used as subject headings are wrapped with the top level <subject> element; the nameTitleGroup attribute is not needed in that case.

2) Designation of "primary" when there are multiple instances of several top-level elements

The MODS schema 3.4 defined an attribute @usage with the value "primary" to be used with top-level elements <name>, <titleInfo>, <subject>, <genre>, <classification>, <language>, <typeOfResource>. This attribute is used with repeated elements to indicate special prominence of one that is useful for various special purposes such as indexing.

When applied to a <name> element, "primary" indicates the name that would probably be used when citing the resource. This is useful when there are several authors and for citation purposes one is to be selected. This also corresponds to the designation of one name as the "main entry" (in MARC, 1XX) in the AACR environment while other names are cited as added entries (in MARC, 7XX). The "primary" name would be used with the resource title for the citation, and also would be the name that would be associated with the uniform title when one is present.

When applied to a <subject>, <genre>, <classification>, <typeOfResource>, or <language> in a record, “primary” would indicate which is most prominent in the resource when there are multiple genres, subjects, class numbers, types, or languages cited in the record.

Note that @usage was previously defined only for <location><url> with the single value "primary display." It indicated the URL that was most important for display to end users. That value name is overly restricted to display needs so the value "primary" is being defined for the additional use of @usage described above. For consistency, "primary" is also being added to the value list defined for <location><url> @usage. The intent of the Committee is that value "primary display" in <location><url> be deprecated in favor of "primary" in a future MODS version. Use of "primary" instead or "primary display" is therefore recommended in the <url> attribute.

EX - In the following example the name Palestrina is both linked via the @nameTitleGroup to the work uniform title and is also designated as the "main entry" for the manifestation title via the @usage attribute.

<titleInfo>
     <title>Canticum canticorum</title>
</titleInfo>
<titleInfo type="uniform" nameTitleGroup="1">
     <title>Motets</title>
     <partNumber>(1583)</partNumber>
</titleInfo>
<name type="personal" nameTitleGroup="1" usage=”primary”>
     <namePart>Palestrina, Giovanni Pierluigi da</namePart>
     <namePart type="date">1525?-1594</namePart>
</name>
<name type="personal">
     <namePart>Picotti, Livio.</namePart>
     <role>
          <roleTerm authority="marcrelator" type="code">prf</roleTerm>
     </role>
</name>
<name type="corporate">
     <namePart>Capella Ducale</namePart>
     <role>
          <roleTerm authority="marcrelator" type="code">prf</roleTerm>
     </role>
</name>

EX - Situation in which the arranger is considered the primary name in the record:

<name type="personal" usage="primary">
     <namePart>Manoloff, Nick</namePart>
     <role>
          <roleTerm type="code" authority="marcrelator">arr</roleTerm>
          <roleTerm type="text" authority="marcrelator"> Arranger</roleTerm>
     </role>
</name>
<name type="personal">
     <namePart>Field, Carl</namePart>
     <role>
          <roleTerm type="code" authority="marcrelator">lyr</roleTerm>
          <roleTerm type="text" authority="marcrelator">Lyricist</roleTerm>
     </role>
</name>

EX - In the following example the cataloger is designating "popular song" as the most important attribute:

<genre usage="primary">Popular song</genre>
<genre>Sheet music</genre>

3) Link for transliterations and translations of the same

The MODS schema 3.4 defined a new attribute @altRepGroup (with string values) to be used with top-level elements. This attribute is used to link alternate representations of the same element content, such as different scripts, transliterations, and translations. The same attribute value is applied to each of the element instances to be linked.

EX

<name type="personal" script="Latn" altRepGroup="8">
     <namePart>Būrī, Muhammad al-Tihāmī,</namePart>
     <namePart type="date">d. 1827</namePart>
</name>
<name type="personal" script="Arab" altRepGroup="8">
     <namePart>بوري، محمد التهامي،</namePart>
     <namePart type="date">d. 1827</namePart>
</name>



Attribute @altRepGroup applies to all MODS top-level elements with the exception of <relatedItem>, however, it applies to those top-level elements when used within <relatedItem>.

4) Data sharing restriction indicator

The MODS 3.4 schema defined a new attribute @shareable with one value "no" to the <tableOfContents> and <abstract>. It is used for data that may be proprietary or is rights protected and should not be used outside of a local system (such as providing to harvesters).

EX
<abstract shareable="no">Landscape features can have an important influence on the characteristics of populations, often resulting in heterogeneity in demographic processes. Therefore, local measurements of population [abstract shortened for example] importance for conservation management strategies for migratory species. (Canadian Journal of Zoology 84 (6): 855-864 June 2006 in ISI Web of Knowledge</abstract>

EX
<tableOfContents shareable="no">Editorial board -- Update of autism: a review of 1300 reports puiblished in 2008 / John R. Hughes -- Effect of repeated administration of Annona diversifolia Saff. (ilama) extracts and palmitone on rat amygdala kindling / Ma. Eva Gonzalez-trujana -- [contents shortened for example] -- Psychosocial impairments in children ith epilepsy depend on the side of the focus / Krystyna A. Mathiak [Contents shortened for example </tableOfContents>

5) Extend language, script, and transliteration for all elements

The attributes @lang, @xml:lang, @script, and @transliteration currently defined for top level elements were defined for all textual MODS elements in order to have more flexibility for adding specific elements to a MODS record using multiple languages.
These attributes are described in Attributes used throughout the schema.

6) Extend the @displayLabel to all top-level MODS elements

The MODS 3.4 schema extends the attribute @displayLabel to <name>, <typeOfResource>, <genre>, <originInfo>, <language>, <targetAudience>, <subject>, and <recordInfo>. This will make MODS overall more consistent, and promotes easier use of MODS as a back-end format for customized cataloging and discovery systems. The attribute contains additional text associated with the element value when necessary for display purposes.

7) Add attribute for specifying authorized form to subject subelements

The MODS 3.4 schema extends the attribute @authority to most of the subelements of <subject> so that the mixture of authorities may be specified. For example:

EX
<subject authority="lcsh">
     <name type="personal" authority="naf">
          <namePart>Kuper, Peter</namePart>
          <namePart type="date">1958-</namePart>
     </name>
</subject>

8) Add URI linking for authoritative data

The MODS 3.4 schema defines two new attributes @authorityURI and @valueURI to elements that have @authority with the following definitions:

authorityURI – A URI uniquely identifying the vocabulary from which the controlled term has been selected, as assigned by the body responsible for the maintenance of the vocabulary. URIs identifying authorities may or may not be dereferenceable to human- or machine-readable information on the authority file, controlled vocabulary, or thesaurus.

valueURI – A URI uniquely identifying the term or controlled value, as assigned by the body responsible for the maintenance of the vocabulary. URIs identifying terms may or may not be dereferenceable to human- or machine-readable records for the term.

For name-title uniform title headings, the title portion is the distinctive part (the name portion of a name-title heading may be used in more than one name-title heading in a record), so <titleInfo> is where authorityURI and valueURI attributes (or any other identifier values) for the name-title heading are placed.

9) Family type added to names element

The MODS 3.4 schema adds the value "family" to the @type under <name> to indicate that the named entity is a family name. This value is used to express familial authorship. This type of authorship is common with archival materials. Other rules and models, such as Resource Description and Access and Functional Requirements for Authority Data also consider families as entities that can be creators of resources.

EX
<name type="family">
     <namePart>Brooks family</namePart>
     <role><roleTerm type="text" authority="marcrelator">creator</roleTerm>
     </role>
</name>

10) Values added for more types of issuance of resources

The MODS 3.4 schema adds the values "single unit ", "multipart monograph", "serial", "integrating resource" as enumerated values for <originInfo><issuance>. They are more precise distinctions than the more general "monographic" and "continuing" currently defined and which will be kept. The following definitions will be used:

single unit - A type of monographic resource that is issued either as a single physical unit (e.g., as a single-volume monograph) or, in the case of an intangible resource, as a single logical unit (e.g., as a PDF file mounted on the Web).
multipart monograph - A type of monographic resource issued in two or more parts (either simultaneously or successively) that is complete or intended to be completed within a finite number of parts (e.g., a dictionary in two volumes or three audiocassettes issued as a set).
serial - A type of continuing resource issued in successive parts, usually bearing numbering, that has no predetermined conclusion (e.g., a periodical, a monographic series, or a newspaper). Includes resources that exhibit characteristics of serials, such as successive issues, numbering, and frequency, but whose duration is limited (e.g., newsletters of events) and reproductions of serials.
integrating resource - A type of continuing resource that is added to or changed by means of updates that do not remain discrete and are integrated into the whole. An integrating resource may be tangible (e.g., a loose-leaf manual that is updated by means of replacement pages) or intangible (e.g., a Web site that is updated either continuously or on a cyclical basis).

The existing values will be revised as follows:

continuing - A resource that is issued over time with no predetermined conclusion. Continuing resources include serials and ongoing integrating resources, i.e. those that are continuously updated. Alternatively, more specific values distinguishing "serial" from "integrating resource" may be used.
monographic - A resource that is either complete in one part or intended to be completed in a finite number of separate parts. Alternatively, more specific values distinguishing "single unit" from "multipart monograph" may be used.

Note: Collection, which designates an aggregation level, is included in the collection attribute in the <typeOfResource> element.

11) Accommodate designation of script of the resource

The MODS 3.4 schema adds the <scriptTerm> subelement under <language> with attributes: type (code, text), authority, authorityURI, and valueURI. This will allow explicit and standardized indication (using iso15924) of the script used in a resource.

Use <scriptTerm> to indicate the script in which the language is rendered. As with <languageTerm>, <scriptTerm> may be repeated to convey different representations of the same script.

EX
<abstract> ... work on ethics in 3 books ... followed by two short treatises ... the first of which is in Arabic ... and the second is in Arabic and Ottoman ....</abstract>
<language objectPart="Primary work and first treatise">
     <languageTerm authority="iso639-2b" type="code">ara</languageTerm>
     <languageTerm lang="en" type="text">Arabic</languageTerm>
     <scriptTerm authority="iso15924" type="code">Arab</scriptTerm>
</language>
<language objectPart="Second treatise">
     <languageTerm authority="iso639-2b" type="code">ota</languageTerm>
     <languageTerm lang="en" type="text">Ottoman Turkish</languageTerm>
     <scriptTerm authority="iso15924" type="code">Arab</scriptTerm>
</language>
<language objectPart="Second treatise">
     <languageTerm authority="iso639-2b" type="code">ara</languageTerm>
     <languageTerm lang="en" type="text">Arabic</languageTerm>
     <scriptTerm authority="iso15924" type="code">Arab</scriptTerm>
</language>

EX
<abstract>A Persian-Turkish literary dictionary</abstract>
     <language>
      <languageTerm authority="iso639-2b" type="code">per</languageTerm>
     <languageTerm authority="rfc3066" type="code">fa</languageTerm>
     <scriptTerm authority="iso15924" type="code">Arab</scriptTerm>
     <scriptTerm type="text">Arabic</scriptTerm>
</language>
<language>
     <languageTerm authority="iso639-2b" type="code">ota</languageTerm>
     <scriptTerm authority="iso15924" type="code">Arab</scriptTerm>
     <scriptTerm type="text">Arabic</scriptTerm>
</language>

12) Marker for supplied data added

The MODS 3.4 schema adds the 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 (such as a cataloger), indicating that it is possibly questionable.

EX
<originInfo>
     <edition supplied="yes">Second</edition>
     <place supplied="yes"><placeTerm type="text">Chicago</placeTerm>
     </place>
     <publisher supplied="yes">Calumet Music</publisher>
     <copyrightDate encoding="w3cdtf" keyDate="yes">1935</copyrightDate>
</originInfo>

General/structural changes

13) Enabled enumeration of 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 current value, value "3.4", but will now also allow for "3.0", "3.1", "3.2", "3.3".

14) Defined 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, which leads to the exception for <extent> described in 15).

15) Added <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.

16) Reorganized the schema to externalize all elements and definitions and make the schema easier to read.

Consistency changes

17) Added the following attributes to <location><holdingSimple><copyInformation> <note>: @ID, @lang, @script, @transliteration, @xlink, and @xml:lang. Adding these attributes will harmonize the definition of <note> with the other places that <note> element appears in MODS.

18) Added the @type attribute to <location><holdingSimple><copyInformation> <form>. Adding this attribute will harmonize the definition of <form> with its definition within <physicalDescription>.

Miscellaneous changes

19) Added values "edtf" and "temper" to the attribute "encoding" under originInfo dates. This indicates possible use of the Extended Date Time Format or the TEMPER format.

edtf – This value is used for dates coded according to Extended Date Time Format
which in consistent with ISO 8601 but extends it to express special forms of dates that are not covered by w3cdtf and iso8601, such as open ended ranges.

temper – This value is used for dates coded according to Temporal Enumerated Ranges. TEMPER is a simple date and time syntax for representing points, lists, and ranges of timestamps. The syntax is designed to be trivial to parse, easy for humans to read, and friendly to basic lexical sorting algorithms.

EX
<originInfo>
<dateOther encoding="edtf">unknown/2009</dateOther>
</originInfo>

EX
<subject>
<temporal encoding="edtf">20050705/20050706</temporal>
</subject>

20) Additional related item types added

Added values "references" and "reviewOf" to <relatedItem> attribute @type. Mechanisms for extending the list of relatedItem types will be considered for MODS version 4.0.

references - Information concerning a resource cited or referred to in the resource.
reviewOf - Information concerning a resource reviewed in the content of the resource.

EX
<relatedItem type="reviewOf">
<titleInfo><title>The handbook of 20th century literature</title></titleInfo>
</relatedItem>


HOME >> Schemas >> MODS 3.4 Changes

Questions and comments:
Contact Us ( April 21, 2011 )
Legal | External Link Disclaimer