1. Isn't this what <partNumber> and <partName> are for?
2. Making <part> a top-level MODS element still doesn't solve the
problem with <relatedItem> for cases other than 'type="host".'
>>> [log in to unmask] 01/27/05 10:26 AM >>>
We spent a long time a year or so ago defining elements for citations
ended up with an element <part> that was under <relatedItem>.
all MODS elements are defined under <relatedItem>, but in addition
is ONLY defined under relatedItem.
The MODS guidelines say that <part> is limited to use for <relatedItem
type="host"> for generating citations about the location within a host
parent item (although this can't be enforced by the schema).
There are some problems with this. One is that it breaks the content
for relatedItem where it brings in all MODS elements, since <part>
top-level MODS element. The other is that, because MODS requires at
one element, at least one MODS element must be under <relatedItem>,
since <part> is not a MODS element you can't use <part> alone.
We have a large initiative called the National Digital Newspaper
to digitize newspaper pages from 1836-1923. We are planning the
architecture now and plan to use METS and MODS. There will be METS
documents for issues of newspapers with MODS metadata for the issue as
well as possibly for the pages (the pages will be detailed in the METS
structural map at least). There is a need to include information about
enumeration (volume, issue, etc.) about the particular issue being
digitized which is what is being described. It seems more intuitive in
this instance to do this at the MODS level rather than the related
So my proposal is to define <part> as a MODS element. The user could
choose whether to use it at the MODS level or related item level. It
provide more flexibility and would allow relatedItem to be recursive
include any MODS element. It would solve the problem of being required
have one MODS element in addition to <part>. And it wouldn't
any existing records.