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

Top-level Element: <originInfo>

Guidelines for Use

<originInfo> is a container element that contains dates and other information related to publication, origination creation, and issuance of the resource. (Dates associated with the temporal content of the resource belong under <subject><temporal>, and dates associated with the metadata go in <recordInfo>.)

Different instances of <originInfo> may be supplied for different events. It is recommended, but not required, to use a separate instance of for each event, each with an event type.

Specific Attribute Information

eventType

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>. For different places, use different occurrences of <place>.

Specific Attribute Information

type

Top

Subelement: <place><placeIdentifier>

Guidelines for Use

<placeIdentifier> contains a URI that identifies a description of an entity. The entity is sometimes referred to as a Thing, a Real World Object or RWO, whether actual or conceptual.

Top

Subelement: <place><cartographics>

Guidelines for Use

<cartographics> is a container element for the subelements listed above.

Top

Subelement: <place><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.

Top

Subelement: <place><cartographics><projection>

Guidelines for Use

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

Top

Subelement: <place><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.

Top

Subelement: <place><cartographics><cartographicExtension>

Guidelines for Use

<cartographicExtension> may include more detailed information than that accommodated by the MODS schema. Examples are a center point, bounding box, or other syntaxes for expressing coordinates.

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, RDA, or DACS may be used to format the name of the publisher

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

Subelement: <agent>

Guidelines for Use

Each instance of <originInfo> represents an event associated with the resource under description: for example publication, distribution, manufacture, production; indicated by attribute @eventType (or @eventTypeURI). The element <agent>identifies a person or corporate body related to this event. The role may be indicated by using the subelement . See examples below.

Background: The <agent> element is new in version 3.8. In earlier versions the agent was indicated by the <publisher> element. This is because in the very early MODS versions, publication was the only type of event envisioned. So the agent was always the publisher. As MODS evolved, users wanted to describe other types of events, and so <originInfo> was generalized to accommodate these descriptions. However, the agent continued to be indicated by <publisher> which was not generalized to until version 3.8. This caused confusion. For example, when the event type is distribution, and <publisher> is supplied, it is supposed to indicate the distributor, but intuitively, was often interpreted to indicate the publisher. And in some cases <publlisher> actually did indicate the publisher even when the event type was distribution. This was done in an attempt to describe two events within one instance of <originInfo> even though <originInfo> was intended to describe exactly one event. When @eventType was added to MODS (in an earlier version) this rule was made explicit.

Beginning with version 3.8, <publisher> should not be used. Even when supplying the publisher, <agent> should be used rather than <publisher>. However, when accepting a MODS record, if <publisher> is supplied within an instance of <originInfo> it should not be treated as an error. It should be interpreted as if the <agent> element were supplied instead. <agent> is defined using the definition for <name> (nameDefinition), and so any of the <name> subelements may be supplied. The name may be parsed into its components, if desired, a role may be supplied, etc.

Specific Attribute Information

Same attributes as under <name>

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.

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

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.

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.

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.

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.

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 Attribute Information

type

Top

Subelement: <displayDate>

Guidelines for Use

Free text date field that allows a date to be represented in human-readable form in order to display a date as it appears on the resource or to add additional context.

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.

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.

Top

Subelement: <frequency>

Guidelines for Use

Use to define the publication pattern of the item.

Top

EXAMPLES

MODS 3.7 Examples

MODS 3.8 Examples