Rebecca,

I would like to propose an alternative scenario for discussion. First, let
me tell you that Rutgers University Libraries is committed to using MODS as
the primary metadata schema in our Fedora-based digital repository
implementation. Currently the Fedora software uses METS as a wrapper for
digital objects, so I'm approaching this from the METS/MODS angle.

One characteristic of MODS--which it inherited from MARC--is a reliance on
textual description rather than parsable data. I think that's the proper
terminology. Please correct me. What I mean is that our collection
providers here at Rutgers would like some fairly tight access to data about
extent, dimension, condition and so on. MODS tends to limit this type of
data to text fields: <extent>1 sound disc (56 min.) : digital ; 3/4
in.</extent> rather than providing discrete tagging for each component.
This makes it necessary to extend MODS when tighter control is desired.

It seems to me that the <part> element is really an attempt to provide some
of this more precise coding. I would like to see this incorporated fully
into MODS, not just as an element of <relatedItem>. However, I don't
necessarily agree that <part> should just be tacked on to the existing MODS
elements. The subelements of <part> seem to be useful extensions of both
<titleInfo> and <physicalDescription>, providing more precision where it
would be extremely useful.

For example, when I look at <relatedItem><part>, I see a great deal of
overlap with <title>

<titleInfo>
  <title>
  <partNumber>
  <partName>
</titleInfo>

<detail><caption> and <detail><number> isolate the data that normally would
go into <partNumber> as a text description, e.g. 1. Abt Originale or Reihe
B. <detail><title> is equivalent to <partName>. And there's much the same
situation with <physicalDescription><extent> and
<relatedItem><part><extent>.

I wish the more finely grained fielding of the <part> element could be
incorporated into the MODS <titleInfo> and <physicalDescription> elements.

There's more to my suggestion than just wanting consistency. I think that
the use of MODS within METS brings up some interesting issues about using
<relatedItem> to create a complex MODS record vs creating multiple MODS
records. METS packaging allows the latter. In addition, creating multiple
dmd sections in METS gives you IDs to reference from within the METS
structure map. So part of my motive for wanting to beef up the MODS
elements is to allow me to create richer descriptions when I'm creating
multiple records instead of using the <relatedItem> element. It would be
nice to have those precise distinctions that I see in <relatedItem><part>
available within <titleInfo> and <physicalDescription>.

Ruth Bogan
Rutgers University Libraries


> [Original Message]
> From: Rebecca S. Guenther <[log in to unmask]>
> To: <[log in to unmask]>
> Date: 1/27/2005 10:26:02 AM
> Subject: [MODS] MODS part
>
> We spent a long time a year or so ago defining elements for citations and
> ended up with an element <part> that was under <relatedItem>. Currently,
> all MODS elements are defined under <relatedItem>, but in addition <part>
> 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 or
> parent item (although this can't be enforced by the schema).
>
> There are some problems with this. One is that it breaks the content model
> for relatedItem where it brings in all MODS elements, since <part> isn't a
> top-level MODS element. The other is that, because MODS requires at least
> one element, at least one MODS element must be under <relatedItem>, but
> since <part> is not a MODS element you can't use <part> alone.
>
> We have a large initiative called the National Digital Newspaper Program
> 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 the
> 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 item
> level.
>
> 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 would
> provide more flexibility and would allow relatedItem to be recursive and
> include any MODS element. It would solve the problem of being required to
> have one MODS element in addition to <part>. And it wouldn't invalidate
> any existing records.
>
> Rebecca