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
- 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.
- Add to <location> the sub-element <holdingInfo>
Structured, optional and non-repeatable.
- 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>
|