MODS User Guidelines (ver. 3) Home » Top-level Elements and Attributes » Top-level Element: <subject>

Top-level Element: <subject>

GUIDELINES | EXAMPLES | MAPPINGS

GUIDELINES FOR USE

<subject> is a container element that contains subelements relating to the subject aspect of the resource.

If the subject is a controlled heading from an authoritative list, use the authority attribute to indicate which authority was used. If no authority attribute is present, the data is assumed to be an uncontrolled term.

If it is not desired to parse the subject subelements, use <subject><topic> and a string.

Repeat <subject> for each subject string.

Specific DLF/Aquifer Guidelines

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require, when applicable, the use of at least one <subject> element in a record. Values for <subject> indicate what content is found within or represented by the work, and typically answer such questions as who, what, where, and when.

Description of subject content may not be applicable to some works; in those cases, use of a <subject> element is not required. Whether or not the use of <subject> is applicable depends upon who might search for an item outside its local context and how they are likely to search for it. For instance, topical subject content may not apply to some items, such as abstract art. If researchers are likely to be interested in the form or genre of an item, and not its subject content, using the <genre> element (not the subelement under <subject>) may be most appropriate. However, in many instances, using appropriate <subject> values can greatly enhance users' ability to locate relevant works.

Enter as many specific terms as necessary to capture subject content, and be consistent in the formatting of subject terms. DLF/Aquifer guidelines highly recommend the use of subject values from a controlled vocabulary or formal classification scheme and the designation of this list in the authority attribute. Select controlled vocabularies that are most relevant to and frequently used by the communities likely to benefit from the described materials, and explicitly identify this source. If a subject term is appropriate or well-known among a group of users, and it is not included in a formal scheme, it may still be included, but the source of the term should be identified. Place any locally-developed vocabulary term in a separate <subject> element and define its authority as "local". If the term is not controlled by a formal subject scheme or a locally developed scheme, the authority attribute is not used. New subject authority vocabularies can be registered with the Library of Congress; email ndmso@loc.gov to suggest an authority.

Subelements within <subject> are used to differentiate subject content. While MODS does allow for placing multiple values in a single <subject><topic> string, parsing subject terms into separate subelements is the preferred practice and highly recommended in the DLF/Aquifer guidelines. Place distinct, multiple subjects in separate <subject> fields.

Use of the authority attribute is recommended if applicable to record the name of the authoritative list for a controlled value. Specify authority at the <subject> level in most cases (exceptions are <subject><name>, <subject><titleInfo>, and <subject><geographicCode>). If providing subjects from different authorities, use a separate <subject> element for each. This is required even when subjects differ only at the subelement level.

Locally developed terms should be listed separately, with "local" indicated as the source using the authority attribute at the <subject> level.

If the term is uncontrolled (for example, if it is a keyword from legacy records), do not use the authority attribute. Note that the concept of an "uncontrolled term" is misleading: ideally, all terms used as subject values should be controlled, whether that control comes from a formal classification scheme or from a locally developed vocabulary. But the DLF/Aquifer guidelines also recognize that if one is converting legacy records, subject values may not be controlled. However, the recommended best practice is to pull from controlled schema, or to make the locally developed list available.

See the <subject> entry in the DLF/Aquifer Summary of MODS Requirements and Recommendations Table for further information on requirements of this element, its attributes, and subelements.

Aggregator information: Subject matter is a critical piece of information for end users to retrieve and determine the suitability of a resource for informational needs; data providers should assume this field will be exposed by aggregators. Care should be taken in situations in which subjects are assigned by batch process to ensure that the contents of individual items are represented accurately. Although information on subject authorities is provided via the model proposed in the DLF/Aquifer guidelines, aggregators should not be expected to perform any normalization, linking, or other processing (although they are free to do so). The authority information is important, however, to communicate to the aggregator the nature of subject analysis that has taken place, and to reduce semantic confusion based on local subject lists using the same terms as shared authority files.

The "Subjects/Topics" section in the DLF/NSDL Best Practices for Shareable Metadata discusses the use of subjects. The "Providing supplemental information to service providers" is also relevant.

Element Description

Attributes

authority

authorityURI

valueURI

usage

altRepGroup; xlink; ID; lang; xml:lang; script; transliteration; displayLabel

Subelements

The following subelements are described below:

• <topic>
• <geographic>
• <temporal>
• <titleInfo>
• <name>
• <genre>
• <hierarchicalGeographic>
• <cartographics>
• <geographicCode>
• <occupation>

 Top

Subelement: <topic>

Guidelines for Use

If the type of subject string is unknown, <topic> is used (since <subject> is a container element).

If a controlled subject term is used, indicate authority using the authority attribute at the <subject> level.

Specific DLF/Aquifer Guidelines

While it is highly recommended that subject values be parsed into subelements, they may also be listed as a string under <subject><topic>.

Element Description

Attributes

authority

authorityURI

valueURI

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <topic>.

 Top

Subelement: <geographic>

Guidelines for Use

If a controlled subject term is used, indicate authority using the authority attribute at the <subject> level.

If the geographic name is part of a corporate body name (i.e., United States. Senate), it is coded with the <name> subelement, not <geographic>.

Element Description

Attributes

authority

authorityURI

valueURI

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <geographic>

 Top

Subelement: <temporal>

Guidelines for Use

<temporal> may be expressed as a controlled subject term or as a structured date with an encoding attribute.

If a controlled subject term is used, indicate authority using the authority attribute at the <subject> level.

Specific DLF/Aquifer Guidelines

Normalized dates are critical for effective searching. Dates should be formatted consistently, following the structure dictated by the formatting source used.

If a structured date is used, indicate the formatting source using the encoding attribute. The DLF/Aquifer guidelines recommend using the following value for the encoding attribute:

Note that the point attribute is used to indicate a date range, not a single date.

Use of the keyDate attribute is not recommended. Only one date element in a record should be specified as a key date and the DLF/Aquifer guidelines recommend that the keyDate appear in the <originInfo> element.

Element Description

Attributes

authority

authorityURI

valueURI

encoding; point; keyDate; lang; xml:lang; script; transliteration

Subelements

There are no subelements for <temporal>.

 Top

Subelement: <titleInfo>

Guidelines for Use

See the <titleInfo> section of the guidelines for more explicit guidance.

Specific DLF/Aquifer Guidelines

The DLF/Aquifer guidelines highly recommend using the authority attribute at this level to indicate titles controlled by an authority.

Element Description

Attributes

All attributes defined under the top-level element <titleInfo> may be used except usage, nameTitleGroup, altRepGroup. An authority attribute may be used at this level if desired, in addition to at the highest level (under <subject>).

Subelements

All subelements defined under the top-level element <titleInfo> may be used with this subelement.

 Top

Subelement: <name>

Guidelines for Use

See the <name> section of the guidelines for more explicit guidance.

Specific DLF/Aquifer Guidelines

The DLF/Aquifer guidelines highly recommend using the authority attribute to indicate if a name is controlled by a record in an authority file.

Element Description

Attributes

All attributes defined under the top-level element <name> may be used except usage, nameTitleGroup, and altRepGroup. An authority attribute may be used at this level if desired, in addition to at the highest level (under <subject>).

Subelements

All subelements defined under the top-level element <name> may be used.

 Top

Subelement: <genre>

Guidelines for Use

If describing the genre of a resource as a whole, use the main <genre> element. This <genre> subelement is used to facilitate mapping of subject authorities that use form subdivisions.

Specific DLF/Aquifer Guidelines

The DLF/Aquifer guidelines make use of this subelement as an option but give strong preference to use of the main <genre> element for form/genre terms whenever possible.

Element Description

Attributes

authority

authorityURI

valueURI

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <genre>.

 Top

Subelement: <hierarchicalGeographic>

Guidelines for Use

<hierarchicalGeographic> is a wrapper element for the hierarchical form of place name, which is both readable by humans and parsable by machines. This form can be applied to the degree of specificity that is known or relevant and used to generate browsable hierarchies even when values are specified to different levels.

Explicit inclusion of the complete hierarchy is of potential benefit for automated consultation of a gazetteer to derive map coordinates or to support a map-based interface for searching by country or state.

Element Description

Attributes

authority

authorityURI

valueURI

Subelements

The following subelements are defined for <hierarchicalGeographic>. In general, use the term most commonly used in the original language or its translation for the geographic entity. First order political divisions may have different terms depending on the country. For instance, first order political divisions in the U.S. are states; in Canada provinces; in United Kingdom, England, Scotland, and Wales are countries and next order divisions (e.g. Yorkshire) are counties.

• <continent> – Includes Asia, Africa, Europe, North America, South America.
• <country> – Name of a country, i.e. a political entity considered a country.
• <province> – Includes first order political divisions called provinces within a country, e.g. in Canada.
• <region> – Includes regions that have status as a jurisdiction, usually incorporating more than one first level jurisdiction.
• <state> – Includes first order political divisions called states within a country, e.g. in U.S., Argentina, Italy. Use also for France département.
• <territory> – Name of a geographical area belonging to or under the jurisdiction of a governmental authority.
• <county> – Name of the largest local administrative unit in various countries, e.g. England.
• <city> – Name of an inhabited place incorporated as a city, town, etc.
• <citySection> – Name of a smaller unit within a populated place, e.g., neighborhoods, parks, or streets.
• <island> –Name of a tract of land surrounded by water and smaller than a continent but is not itself a separate country.
• <area> – Name of a non-jurisdictional geographic entity.
• <extraterrestrialArea> – Name of any extraterrestrial entity or space, including solar systems, galaxies, star systems, and planets as well as geographic features of individual planets.

 Top

Subelement: <cartographics>

Guidelines for Use

<cartographics> is a container element; data content is entered in the subelements.

If desired, cartographic elements may be bound together with a geographic name (hierarchical or otherwise) within a <subject> element.

Specific DLF/Aquifer Guidelines

This subelement is not fully developed; specific recommendations for its use are not possible at this point. Use established standards in your area to guide use of this subelement.

Element Description

Attributes

There are no attributes for <cartographics>.

Subelements

The following subelements are described below:

• <coordinates>
• <scale>
• <projection>

 Top

Subelement: <cartographics><coordinates>

Guidelines for Use

One or more statements may be supplied. If one is supplied, it is a point (i.e., a single location); if two, it is a line; if more than two, it is an n-sided polygon where n=number of coordinates assigned. No three points should be co-linear, and coordinates should be supplied in polygon-traversal order.

Element Description

Attributes

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <coordinates>.

 Top

Subelement: <cartographics><scale>

Guidelines for Use

<scale> may include any equivalency statements, vertical scales, or vertical exaggeration statements for relief models and other three-dimensional items.

Element Description

Attributes

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <scale>.

 Top

Subelement: <cartographics><projection>

Guidelines for Use

Includes the name of the projection and any associated information related to the properties of the projection, where applicable.

Element Description

Attributes

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <projection>.

 Top

Subelement: <geographicCode>

Guidelines for Use

A geographic code that represents the same entity as a term in the <geographic> subelement is included within the same <subject> element.

Specific DLF/Aquifer Guidelines

The DLF guidelines recommends the use of a <geographic> or <hierarchicalGeographic> value in addition to <geographicCode> to improve the searchability of a record.

The geographic code should be from an established encoding scheme that is indicated in the authority attribute. For those not already using MARC, the DLF/Aquifer guidelines recommend using "iso3166" as the authority value for <geographicCode>.

Element Description

Attributes

authority

authorityURI

valueURI

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <geographicCode>.

 Top

Subelement: <occupation>

Guidelines for Use

<occupation> is not used to list the occupations of the creators of the described materials, unless those occupations are significantly reflected in the materials themselves or bear some relationship to the materials.

Specify authority at the main <subject> element level.

Element Description

Attributes

authority

authorityURI

valueURI

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <occupation>.

 Top

EXAMPLES

 Top

MAPPINGS

MARC Mapping (Bibliographic)

<subject> with the authority attribute = MARC 21 field 6XX, with the second indicator value

<subject><topic> with authority attribute defined = MARC 21 fields 650 or 6XX subfields x and v

<subject><topic> with no authority attribute defined = MARC 21 field 653

<subject><geographic> = MARC 21 field 651 subfield z and 6XX

<subject><temporal> = MARC 21 fields 045 and 6XX subfield y.

<subject><titleInfo> = MARC 21 field 630

<subject><name> = MARC 21 fields 600, 610, 611.

<subject><genre> = MARC 21 6XX fields, subfield v

<subject><hierarchicalGeographic> = MARC 21 field 752.

<subject><cartographics> = MARC 21 fields 034 and 255.

<subject><cartographics><coordinates> = MARC fields 034, subfields d, e, f, and g or 255, subfield c

<subject><cartographics><scale> = MARC field 255, subfield a

<subject><cartographics><projection> = MARC field 255, subfield b

<subject><geographicCode> = MARC 21 field 043

<subject><occupation> ≈ MARC 21 field 656

See also MARC Mapping to MODS for the <subject> element.

Dublin Core Mapping

Using the basis provided by the MODS to Dublin Core Metadata Element Set Mapping these guidelines suggest the following crosswalks between MODS element <subject> and simple Dublin Core elements.

MODS examples expressed in Dublin Core:

 Top

Last Updated: February 18, 2011