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

Top-level Element: <originInfo>

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

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

Subelements

The following subelements are described below:

• <place>
• <publisher>
• <dateIssued>
• <dateCreated>
• <dateCaptured>
• <dateValid>
• <dateModified>
• <copyrightDate>
• <dateOther>
• <edition>
• <issuance>
• <frequency>

 Top

Subelement: <place>

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

Subelements

The following subelement is described below:

• <placeTerm>

 Top

Subelement: <place><placeTerm>

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

authority

authorityURI

valueURI

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>

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

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>

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

Subelements

There are no subelements for <dateIssued>.

 Top

Subelement: <dateCreated>

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

Subelements

There are no subelements for <dateCreated>.

 Top

Subelement: <dateCaptured>

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

Subelements

There are no subelements for <dateCaptured>.

 Top

Subelement: <dateValid>

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

Subelements

There are no subelements for <dateValid>.

 Top

Subelement: <dateModified>

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

Subelements

There are no subelements for <dateModified>.

 Top

Subelement: <copyrightDate>

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

Subelements

There are no subelements for <copyrightDate>.

 Top

Subelement: <dateOther>

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

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

Subelements

There are no subelements for <dateOther>.

 Top

Subelement: <edition>

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

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <edition>.

 Top

Subelement: <issuance>

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>

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

authorityURI

valueURI

lang; xml:lang; script; transliteration

Subelements

There are no subelements for <frequency>.

 Top

EXAMPLES

 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:

 Top

Last Updated: August 14, 2013