The Library of Congress » Standards » MODS Official Web Site

Top-level Element: <originInfo>

Element <originInfo>
Definition Information about the origin of the resource, including place of origin or publication, publisher/originator, and dates associated with the resource.
Attributes eventType; displayLabel; altRepGroup; lang; xml:lang; script; transliteration
Subelements <place> <publisher> <dateIssued> <dateCreated> <dateCaptured> <dateValid> <dateModified> <copyrightDate> <dateOther> <edition> <issuance> <frequency>

GUIDELINES | EXAMPLES | MAPPINGS

GUIDELINES FOR USE

<originInfo> is a container element that contains all subelements related to publication and origination information. It includes all dates associated with the creation, issuance, and/or publication of the resource. Dates associated with the temporal content of the resource go under <subject>, and dates associated with the metadata go in <recordInfo>. Data is input only within each subelement.

Specific DLF/Aquifer Guidelines

The DLF/Aquifer Implementation Guidelines for Shareable MODS Records require the use of at least one <originInfo> element with at least one date subelement in every record, one of which must be marked as a key date.

Use of the <place>, <publisher>, and <edition> subelements are recommended if applicable. The DLF/Aquifer guidelines make no recommendation on the use of the elements <issuance> and <frequency>.

The examples given in the DLF/Aquifer guidelines represent a sample of the types of decisions a metadata provider might make about which data is important to expose.

See the <originInfo> 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: Aggregators in the current environment will likely use dates for providing access to materials by their creation date, including limiting searches to resources created within a certain date range, or browsing by the date of creation of a resource. The keyDate attribute signifies to an aggregator which date is most important, but aggregators should also make use of indication of date ranges, uncertain dates, and the like to improve end user discovery. Other dates and other <originInfo> data would likely be displayed to a user, to give that user the information he or she needs to determine if the resource is of interest.

The "Date Practices" section of the DLF/NSDL Best Practices for Shareable Metadata discusses the use of dates. Other elements in <originInfo> are not covered.

Element Description

Attributes

eventType

Definition

Identifies a type of event.

Application

There is no controlled list of identifier eventTypes. Suggested values include, but are not limited to, the following values: 'production', 'publication', 'distribution', 'manufacture'.

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

The following subelements are described below:

Top

Subelement: <place>

Definition Name of a place associated with the issuing, publication, release, distribution, manufacture, production, or origin of a resource.
Attributes supplied
Subelements <placeTerm>

Guidelines for Use

<place> is a container element for <placeTerm> to indicate place of publication/origin. <place> is used in connection with the origin of a resource, i.e., creation, publication, issuance, etc. The <place> element should be omitted if no information about the originating place of the resource is known.

Descriptive standards such as AACR2 may be used to determine which places to record for published resources. If a place of origin is known for an unpublished resource, it should also be recorded in <place><placeTerm>.

Places as subjects are included under <subject><geographic> or <subject><hierarchicalGeographic>.

Repeat <place> for recording multiple places.

Element Description

Attributes

supplied

Definition

An indication that the place information did not come from the resource itself.

Application

This attribute is used as supplied="yes" when the place information has been supplied from an external source, not from the resource.

Subelements

The following subelement is described below:

Top

Subelement: <place><placeTerm>

Definition Used to express place in a textual or coded form.
Element <placeTerm>
Attributes type; authority; authorityURI; valueURI; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

If both a code and a term are given that represent the same place, use one <place> and multiple occurrences of <placeTerm>. If different places, repeat <place><placeTerm>.

Specific DLF/Aquifer Guidelines

If <placeTerm> is used, the DLF/Aquifer guidelines require the use of the type attribute.

For each <placeTerm> given, the DLF/Aquifer guidelines require including, at a minimum, a textual version of the place, with the attribute type="text".

If the place given is a country, and the name of that country has been selected from the MARC country code list or the ISO3166 standard list of country names, add an authority attribute to <placeTerm> indicating the source of the country name, and add a second <placeTerm> subelement within <place> indicating the coded version of that country name from the chosen authoritative list, with the attribute type="code" and an authority attribute indicating the source of the country code.

Element Description

Attributes

type

Definition

Indicates whether the place is expressed in a coded or textual form.

Application

This attribute may be used with the following values:

  • text – This value is used to express place in a textual form.
  • code – This value is used to express place in a coded form.

authority

Definition

The controlled list from which the value is taken.

Application

This attribute may be used with the following values:

  • marccountry – This source code is used for the MARC country codes. See the MARC Code List for Countries for a listing of the codes and place names.
  • iso3166 – This source code is used with country codes from ISO 3166. See the ISO 3166 Code Lists External Link for a listing of the codes.

authorityURI

Definition

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.

Application

URIs identifying authorities may or may not be dereferenceable to human- or machine-readable information on the authority file, controlled vocabulary, or thesaurus.

valueURI

Definition

A URI uniquely identifying the term or controlled value from a vocabulary, as assigned by the body responsible for the maintenance of the vocabulary.

Application

URIs identifying terms may or may not be dereferenceable to human- or machine-readable records for the term.

lang; xml:lang; script; transliteration

See the Attributes used throughout the schema for description for each.

Subelements

There are no subelements for <placeTerm>.

Top

Subelement: <publisher>

Definition The name of the entity that published, printed, distributed, released, issued, or produced the resource.
Attributes supplied; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

Record in <publisher> a named entity determined to be the publisher/originator for a resource or a statement about publication/origin. Descriptive standards such as AACR2 may be used to format the name of the publisher.

Specific DLF/Aquifer Guidelines

Information about an institution responsible for digitizing and delivering online a previously published resource should be included in <note>, rather than <originInfo><publisher>.

Element Description

Attributes

supplied

Definition

An indication that the publisher information did not come from the resource itself.

Application

This attribute is used as supplied="yes" when the publisher information has been supplied from an external source, not from the resource.

lang; xml:lang; script; transliteration

See the Attributes used throughout the schema for description for each.

Subelements

There are no subelements for <publisher>.

Top

Subelement: <dateIssued>

Definition The date that the resource was published, released, or issued.
Attributes encoding; point; keyDate; qualifier; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

The date may be in textual or structured form. If it is structured, the encoding attribute should specify the format. No good standard for encoding BCE dates in a structured form currently exists; until such time as these recommendations emerge, BCE dates may be represented in textual forms only.

The MODS schema includes several date elements intended to record different events that may be important in the life of a resource. When multiple date elements apply but would contain identical data, institutions may choose to use only one of the relevant date elements. Mark one and only one date as a key date using keyDate="yes" attribute.

When a date is uncertain or cataloger-supplied, indicate this through the use of the qualifier attribute rather than inserting characters such as "ca.", brackets, or a question mark as part of the date string. When only a decade is known, enter a date range for the entire decade and mark the date as questionable. When only a century is known, enter a date range for the entire century and mark the date as questionable.

Specific DLF/Aquifer Guidelines

The use of <dateIssued> and the recording of each date in a structured form rather than a textual form are recommended.

Use of the encoding attribute is recommended. If an exact year is known, the DLF/Aquifer guidelines recommend representing the value using the W3CDTF encoding, which also allows month and day to be specified if known. The W3CDTF encoding is a profile of the more flexible ISO 8601 standard. Using W3CDTF ensures a more predictable format for dates. The DLF/Aquifer guidelines recommend using ISO 8601 encoding only when a date cannot be expressed using W3CDTF.

Use of the point attribute is recommended, if applicable. The point attribute is used to specify whether a date is a start date or an end date if the resource is best described by a date range. Best practice is to use the point attribute only when a date range is indicated, not for single dates.

The DLF/Aquifer guidelines require that every MODS record containing at least one date must have one and only one date element with the attribute keyDate="yes". The key date will be used by aggregators for date indexing, sorting, and display. The date marked as the key date should be the date considered by the metadata provider as the most important for end user access. Frequently this will be the date the item was created or issued. For date ranges, mark the start date of the range intended for date searching as the keyDate.

Use of the qualifier attribute is recommended, if applicable. Best practice is to use this attribute with the appropriate value when a date is approximate, inferred, or questionable, rather than inserting characters such as "ca.", brackets, or a question mark within the date string.

Element Description

Attributes

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <dateIssued>.

Top

Subelement: <dateCreated>

Definition The date of creation of the resource.
Attributes encoding; point; keyDate; qualifier; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

See <dateIssued> for the following information on recording dates: date structure, recording multiple dates, key date marking, and recording unknown date components.

If creation date is also the origination date (as in MARC 21 field 260 subfield $c), use the <dateIssued> element or repeat both <dateCreated> and <dateIssued>.

Specific DLF/Aquifer Guidelines

The use of <dateCreated> and the recording of each date in a structured form rather than a textual form are recommended.

See <dateIssued> for the following additional information from the DLF/Aquifer guidelines on recording dates: use of W3CDTF for encoding dates, recording date ranges, key dates, and use of the point attribute.

Element Description

Attributes

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <dateCreated>.

Top

Subelement: <dateCaptured>

Definition The date on which the resource was digitized or a subsequent snapshot was taken.
Attributes encoding; point; keyDate; qualifier; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

<dateCaptured> is particularly useful for Web resources because of their changeability. This would be a date that the resource was captured and archived.

See <dateIssued> for the following information on recording dates: date structure, recording multiple dates, key date marking, and recording unknown date components.

Specific DLF/Aquifer Guidelines

Use of <dateCaptured> is not recommended by the DLF/Aquifer guidelines.

Element Description

Attributes

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <dateCaptured>.

Top

Subelement: <dateValid>

Definition A date in which the content of a resource is valid.
Attributes encoding; point; keyDate; qualifier; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

See <dateIssued> for the following information on recording dates: date structure, recording multiple dates, key date marking, and recording unknown date components.

Specific DLF/Aquifer Guidelines

Use of <dateValid> is not recommended by the DLF/Aquifer guidelines.

Element Description

Attributes

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <dateValid>.

Top

Subelement: <dateModified>

Definition The date in which a resource is modified or changed.
Attributes encoding; point; keyDate; qualifier; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

See <dateIssued> for the following information on recording dates: date structure, recording multiple dates, key date marking, and recording unknown date components.

Note that <dateModified>is used for modification of the resource, not of the metadata. In some cases a modified resource may be considered a new resource and described as such.

Specific DLF/Aquifer Guidelines

Use of <dateModified> is not recommended by the DLF/Aquifer guidelines.

Element Description

Attributes

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <dateModified>.

Top

Subelement: <copyrightDate>

Definition A date in which a resource is copyrighted.
Attributes encoding; point; keyDate; qualifier; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

See <dateIssued> for the following information on recording dates: date structure, recording multiple dates, key date marking, and recording unknown date components.

Specific DLF/Aquifer Guidelines

The use of <copyrightDate> and the recording of each date in a structured form rather than a textual form are recommended.

See <dateIssued> for the following additoinal information from the DLF/Aquifer guidelines on recording dates: use of W3CDTF for encoding dates, recording date ranges, key dates, and use of the point attribute.

Element Description

Attributes

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <copyrightDate>.

Top

Subelement: <dateOther>

Definition A date that does not fall into another category but is important to record.
Attributes type; encoding; point; keyDate; qualifier; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

See <dateIssued> for the following information on recording dates: date structure, recording multiple dates, key date marking, and recording unknown date components.

<dateOther> may be used with the type attribute to designate a specific kind of date which was not deemed of sufficient general use to have its own date element.

Specific DLF/Aquifer Guidelines

The use of <dateOther> and the recording of each date in a structured form rather than a textual form are recommended.

See <dateIssued> for the following additoinal information from the DLF/Aquifer guidelines on recording dates: use of W3CDTF for encoding dates, recording date ranges, key dates, and use of the point attribute.

Element Description

Attributes

type

Definition

Indicates the kind of date being recorded in this element.

Application

This attribute allows for extensibility of date types so that other specific date types may be designated if not given a separate element in MODS.

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

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <dateOther>.

Top

Subelement: <edition>

Definition Information identifying the version of the resource.
Attributes supplied; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

Resources that constitute the same "edition" generally embody essentially the same content. If no edition statement applies to the resource, do not include the <edition> element.

Specific DLF/Aquifer Guidelines

Descriptive standards such as AACR2 and DACS may be used to determine if an edition statement should be recorded and in what format.

Element Description

Attributes

supplied

Definition

An indication that the edition information did not come from the resource itself.

Application

This attribute is used as supplied="yes" when the edition information has been supplied from an external source, not from the resource.

lang; xml:lang; script; transliteration

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <edition>.

Top

Subelement: <issuance>

Definition A term that designates how the resource is issued.
Attributes None
Subelements None

Guidelines for Use

<issuance> may be used with the following values:

  • 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.
  • 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).
  • 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.
  • 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).

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

Specific DLF/Aquifer Guidelines

The DLF/Aquifer guidelines offer no specific guidance on the use of <issuance>.

Element Description

Attributes

There are no attributes for <issuance>.

Subelements

There are no subelements for <issuance>.

Top

Subelement: <frequency>

Definition A statement of publication frequency in textual form.
Attributes authority; authorityURI; valueURI; lang; xml:lang; script; transliteration
Subelements None

Guidelines for Use

Use to define the publication pattern of the item.

Specific DLF/Aquifer Guidelines

The DLF/Aquifer guidelines offer no specific guidance on the use of <frequency>.

Element Description

Attributes

authority

Definition

Indicates the controlled list from which the value is taken.

Application

The name of the authoritative list for a controlled value is recorded here. See Frequency of Issue Code and Term Source Codes for a list of authority sources. Use the value of "marcfrequency" if the authority used is MARC Frequency of Issue Term List.

authorityURI

Definition

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.

Application

URIs identifying authorities may or may not be dereferenceable to human- or machine-readable information on the authority file, controlled vocabulary, or thesaurus.

valueURI

Definition

A URI uniquely identifying the term or controlled value from a vocabulary, as assigned by the body responsible for the maintenance of the vocabulary.

Application

URIs identifying terms may or may not be dereferenceable to human- or machine-readable records for the term.

lang; xml:lang; script; transliteration

See the Attributes used throughout the schema for descriptions of each.

Subelements

There are no subelements for <frequency>.

Top

EXAMPLES

<originInfo eventType="publisher">
<place>
<placeTerm type="code" authority="marccountry">dcu</placeTerm>
<placeTerm type="text">Washington, DC</placeTerm>
</place>
<publisher>Library of Congress, Cataloging Distribution Service, in collaboration with Follett Software Company</publisher>
<dateIssued>2003</dateIssued>
<edition>7th ed.</edition>
<issuance>monographic</issuance>
</originInfo>
<originInfo eventType="manufacture">
<place>
<placeTerm type="text">Cambridge</placeTerm>
</place>
<publisher>Kinsey Printing Company</publisher>
<dateOther type="manufacture" keyDate="yes" qualifier="inferred">1922</copyrightDate>
</originInfo>
<originInfo eventType="publication">
<copyrightDate encoding="iso8601">20000122</copyrightDate>
<dateCaptured encoding="iso8601">20010712</dateCaptured>
<issuance>continuing</issuance>
</originInfo>
<originInfo eventType="production">
<dateValid encoding="iso8601" point="start">20011008</dateValid>
<dateValid encoding="iso8601" point="end">20011027</dateValid>
</originInfo>
<originInfo eventType="publication">
<place>
<placeTerm type="text">Milan</placeTerm>
</place>
<publisher>F. Lucca</publisher>
<place>
<placeTerm type="text">Florence</placeTerm>
</place>
<publisher>Ducci</publisher>
<place>
<placeTerm type="text">Chiasso</placeTerm>
</place>
<publisher>Euterpe Ticinese</publisher>
<place>
<placeTerm type="text">Naples</placeTerm>
</place>
<publisher>Girard et C.</publisher>
<dateIssued>between 1856 and 1862</dateIssued>
<dateIssued encoding="marc" point="start">1856</dateIssued>
<dateIssued encoding="marc" point="end">1862</dateIssued>
<issuance>monographic</issuance>
</originInfo>
<originInfo eventType=publication>
<place supplied="yes">
<placeTerm type="code" authority="marccountry">nyu</placeTerm>
<placeTerm type="text">New York</placeTerm>
</place>
<publisher>Published for the American Vacuum Society by the American Institute of Physics</publisher>
<dateIssued>1994</dateIssued>
<issuance>monographic</issuance>
</originInfo>
<originInfo eventType="manufacture">
<dateModified encoding="iso8601">20031008</dateModified>
</originInfo>
<originInfo eventType="manufacture">
<dateCreated keyDate="yes">1972-10-08</dateCreated>
</originInfo>
<originInfo eventType="production">
<dateCreated encoding="iso8601" keyDate="yes" qualifier="inferred">1916</dateCreated>
</originInfo>
<originInfo eventType="publication">
<place>
<placeTerm type="code" authority="iso3166">usa</placeTerm>
<placeTerm type="text">United States</placeTerm>
</place>
<dateIssued>1975</dateIssued>
</originInfo>
<originInfo eventType="publication">
<place>
<placeTerm type="code" authority="marccountry">dcu</placeTerm>
<placeTerm type="text">Washington, D.C</placeTerm>
</place>
<publisher>Library of Congress</publisher>
<dateIssued>1998-</dateIssued>
<dateIssued encoding="marc" point="start">1998</dateIssued>
<dateIssued encoding="marc" point="end">9999</dateIssued>
<issuance>monographic</issuance>
</originInfo>
<originInfo eventType="publication>
<place>
<placeTerm type="code" authority="marccountry">cau</placeTerm>
<placeTerm type="text">Menlo Park, CA</placeTerm>
</place>
<publisher>Center for Computer Assisted Research in the Humanities</publisher>
<dateIssued>1985-1988</dateIssued>
<dateIssued encoding="marc" point="start">1985</dateIssued>
<dateIssued encoding="marc" point="end">1988</dateIssued>
<issuance>continuing</issuance>
<frequency authority="marcfrequency">Annual</frequency>
</originInfo>
<originInfo eventType=publication>
<place>
<placeTerm type="code" authority="marccountry">enk</placeTerm>
<placeTerm type="text">England</placeTerm>
</place>
<dateIssued encoding="w3cdtf" keyDate="yes" qualifier="inferred">1855</dateIssued>
<issuance>monographic</issuance>
</originInfo>
<originInfo venetType="publication">
<dateOther point="start">20011008</dateOther>
<dateOther point="end">20011027</dateOther>
</originInfo>

Top

MAPPINGS

MARC Mapping (Bibliographic)

<originInfo><place><placeTerm> with type="text" = MARC 21 field 260 subfield a

<originInfo><place><placeTerm> with type="code" and authority="marccountry" = MARC 21 field 008/15-17

<originInfo><place><placeTerm> with type="code" and authority="iso3166" = MARC 21 field 044 subfield c

<originInfo><publisher> = MARC 21 field 260 subfield b

<originInfo><dateIssued> = MARC 21 field 260 subfield c

<originInfo><dateIssued> with encoding="marc" = MARC 21 008/07-14

<originInfo><dateCreated> is recorded in various places in MARC 21:

  • in general = MARC 21 field 260 subfield g
  • where date of manufacture is substituted for the date of publication = MARC 21 field 260 subfield c
  • for date of original publication = MARC 21 field 534 subfield c
  • for date of reproduction = MARC 21 field 533 subfield d

<originInfo><dateCaptured> ≈ MARC 21 field 033

<originInfo><dateValid> ≈ MARC 21 field 046 subfields m and n

<originInfo><dateModified> ≈ MARC 21 field 046 subfield j

<originInfo><dateCopyright> does not have a single MARC 21 equivalent. A copyright date may be used in 260 subfield c preceded by the letter "c" if it appears that way on the resource.

<originInfo><edition> = MARC 21 field 250

<originInfo><issuance> with value of "continuing" = Leader/07, codes "b," "i", and "s"

<originInfo><issuance> with value of "monographic" = Leader/07, codes "a," "c," "d", and "m"

<originInfo><frequency> for continuing resources in coded form = MARC 21 008/18 or MARC 21 holdings fields 853, 854, and 855 subfield w, frequency

<originInfo><frequency> for continuing resources in textual form = MARC 21 field 310

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

Dublin Core Mapping

As the MODS to Dublin Core Metadata Element Set Mapping makes clear, subelements of <originInfo> map incompletely to Dublin Core elements.

The MODS subelements <place>, <edition>, <issuance>, and <frequency> do not map directly to simple Dublin Core elements. However, a <place> element in combination with a <publisher> element may be combined to map to <dc:publisher> following the AACR2 convention.

All of the date subelements map to <dc:date>. If multiple dates are present in the MODS record, data providers may want to consider mapping only the date indicated as the keyDate to the <dc:date> element.

MODS example expressed in Dublin Core:

<dc:publisher>New York: MacMillan</dc:publisher>
<dc:date>1922</dc:date>

<dc:date>1857-1860</dc:date>
<dc:date>2500 B.C.E.</dc:date>

<dc:date>1855</dc:date>

Top

Last Updated: August 2, 2018