The Library of Congress >> Standards >> MODS
Metadata Object Description Schema: Official Web Site

HOME >> MODS Holdings Information

MODS Holdings Information

June 7, 2006

This is a proposal for support of holdings information within a MODS record.

General Approach

Current Situation

Currently, element <location> is structured into two sub-elements, <physicalLocation> and <url>, thus…

<location>

<physicalLocation>
<url>

< /location>

Both <physicalLocation> and <url> are optional and repeatable within <location>, which is itself repeatable.

Proposal

  1. Add to <location> the sub-element <form>
    Unstructured, optional, non-repeatable.
    Present if the resource is available in more than one form. More than one form requires another instance of <location>. This is equivalent MARC Holdings 842 or 007/00-01.
  2. Add to <location> the sub-element <holdingInfo>
    Structured, optional and non-repeatable.
  3. Add a rule that at least one of <physicalLocation> and <url> must be present in an instance of <location>.

Thus:

<location>

< physicalLocation> optional, repeatable; must occur if <url> does not.
< url> optional, repeatable.
< form> optional, non-repeatable.
< holdingInfo> optional, non-repeatable.

< /location>

Any instance of <location> (and as noted above there may be multiple instances) includes one or more <physicalLocation> and/or <url> elements, zero or one <form>, and zero or one <holdingInfo> element.

If <holdingInfo> is present

An instance of <location> where <holdingInfo> is present corresponds to a single holding, where holding information is in element <holdingInfo>. (If a different holding is to be reported, it requires a different instance of <location>.) There may be multiple instances of <physicalLocation> and/or <url> within this single instance of <location> and if so they all correspond to the same holding. (Multiple copies with different holdings require different instances of <location>. In general multiple copies may have the same or different holdings.)

If <holdingInfo> is not present

This document does not prescribe any rules that relate an instance of <location> to any holding information, when <holdingInfo> is not present.

The <holdingInfo> element

< holdingInfo> will be defined to include:

  • A set of internally defined (new) mods elements, all optional.
  • Optionally, external elements (e.g. defined in external schemas).

Thus for example:

< holdingInfo>

internally defined MODS holding element1
internally defined MODS holding element2
etc.
….
external holding element1
external holding element2
etc.
……

< /holdingInfo>

The external elements will be accommodated in the MODS schema in a manner similar to the MODS <extension> element. Thus:

  • One or more valid instances of external schemas, or
  • arbitrary, non-namespaced elements.

If the set of internally defined elements meets the user or profile requirements, then no external elements need be included. That would be the simplest case.

The next-simplest case would be a single schema defining a set of elements to complement the internal elements. (That is, the set of internal elements does not completely satisfy the user or profile requirements, and a schema has been defined to cover the missing elements.)

Alternatively, there may be an off-the-shelf schema that meets the user/profile needs, though it overlaps with the internal elements. In that case, that schema might be used in lieu of the internal elements.

Internally Defined MODS Elements

The internal MODS elements are yet to be determined. One proposed set is as shown in this table:

<copy>

Structured, optional, repeatable.
Specifies which copy of the resource via indication of sublocation, and/or its shelfmark. Also contains a copy specific note if applicable. From MARC 852.Subelements:

  • <subLocation >
    Optional, non-repeatable.
    The branch library or other sub-location holding a copy of the document. From MARC 852 $b, $c, $e
  • <shelfMark>
    Optional, non-repeatable.
    Shelfmark or other location identification code for a copy. From MARC 852 $h-$m, $t
  • <copyNote displayLabel=…>
    Optional, non-repeatable.
    Notes relating to a specific copy of a document. Attribute displayLabel indicates the type of note. From MARC 852 $z
<textHold type= …> Optional, repeatable.
A textual description of the enumeration and chronology of the material, eg. volume details of a periodical. From MARC Holdings 866-868 or 853-855/863-865. The attribute type is “bib” (bibliographic) (if MARC 863 or 866), “sup” (supplement) (if MARC 864 or 867), or “ind” (index) (if MARC 865 or 868).


Summary Layout

Following is a layout of the <location> element, assuming the set of internal elements above.

< location>

< physicalLocation>
< url>
< form>
< holdingInfo>

<copy>

< subLocation>
<shelfMark>
<copyNote>

< /copy>
< textHold>
external elements

< holdingInfo>

< /location>

Example (made up)

<location>

< !-- Holdings for a print copy of a serial that DCPL holds in its science library. One element from an external schema is used for an object id. -->

<physicalLocation>DCPL</physicalLocation>
< form>print</form>
< holdingInfo>

< copy>

< subLocation>SciLib</sublocation>
<shelfMark> Z671.L7 c.1 </shelfMark>
<copyNote>Fragile, handle with care.<copyNote>

< /copy>
< textHold type=”bib”>v.10-40</textHold>
<localHolds xmlns= http://copac.ac.uk/schemas/holdings/v1>

<objId>12345</objId>

</localHold>

< holdingInfo>

< /location>


< location>

< !-- Holdings of an electronic serial that DCPL has access to. The resource is at the URL indicated. -->

< physicalLocation>DCPL</physicalLocation>
< url>http://www.dclibrary.org/h5678 </url>
< form>electronic</form>
< holdingInfo>

< textHold type=”bib”>v.30-40</textHold>

< holdingInfo>

< /location>

 


HOME >> MODS holdings information

Questions and comments:
Contact Us ( January 2, 2008 )