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
which in MODS would be:
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:
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.