I think that this is a reasonable compromise. What seems obvious is that
one person's whole will be someone else's part, and yet someone else's
part of a part. Allowing physical parts to be described either as
primary entries or as related entries is a necessity. I'm sure that some
users will want to express parts as a multi-level hierarchy, but there
are times when you really don't want the baggage of the whole thing.
(It's much like hierarchy in geography - should every place name begin
with "universe - earth - ..."?)

It's kind of a shame that we named it "part" -- I think that's why we
ended up confusing it with the "part" subfields of the title. Can the
documentation make this clear? I would tend to describe this as
referring to separate physical parts, but that doesn't really work for
electronic journals should someone catalog a single issue. Maybe it is
physical if it has a single link?


Rebecca S. Guenther wrote:

>Now I'm going to review my recent thinking on the use of <part> having
>discussed this with various people and having read the recent messages.
>The way I see it there's a distinction between the use of titleInfo with
><title>, <partName>, and <partNumber> and the <part> that we're talking
>about. We've used the former in MARC (245$a, $p, $n) historically to
>indicate part names/numbers that are subordinate to the title. They are
>bibliographic units that are logical parts of the title. I see this as
>different from the situation we have with newspaper issues, in that an
>issue is a structual/physical part of the main bibliographic unit rather
>than an intellectual one. The use of title/partName/partNumber would be
>for a distinct intellectual item.
>Example: 245 00$aAnnual report of the Minister of Supply and Service
>Canada under the Corporations and Labour Unions Returns Act.$nPart
>II,$pLabour unions
>which in MODS would be:
><titleInfo><title>Annual report
>of the Minister...</title><partNumber>Part II</partNumber><partName>Labour
>For the issue of a newspaper I still think it would be better to define
><part> at the MODS level, rather than just under relatedItem. This would
>be for a physical rather than intellectual component of something. So in
>the case of the newspaper issue we might have:
><titleInfo><title>Washington observer</title></titleInfo>
><part><detail type=volume><number>1</number></detail>
>We would also have <originInfo><dateIssued> that might in cases of
>newspapers be the only enumeration.
>You would then have a relatedItem to the host title (the intellectual
>title) that could just be an identifier (e.g. ISSN) or whatever you want
>to include and optionally you could include that same title in the
>description of the issue (which I included above).
>So when to use <part> with relatedItem? I would say the case of the
>article within a larger work. This could be considered a separate
>intellectual entity that has its own identity. You would then
>designate the location within the larger work in related item using
><part>. This is different than the issue which is a separate structural
>(i.e. physical) part.
>Does any of this make sense?
>As to the question of parsing the <extent> element under
><physicalDescription>, we did consider that in the first version of MODS.
>But we were considering MODS a simplification of MARC so decided not to.
>(guess what, it's not so simple any more!) However, if that sort of detail
>is needed, we could reconsider what we might want to do to enhance that
>On Thu, 27 Jan 2005, Andrew E Switala wrote:
>>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>
>>isn't a
>>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.

Karen Coyle / Digital Library Consultant
[log in to unmask]
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234