On Fri, 28 Jan 2005, Ruth Bogan wrote:
> > 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?
> Yes, completely. But couldn't you also describe that article on its own,
> using MODS? And if so, why wouldn't you want to provide the same
> descriptive possibilities as you had when you were describing it as a
> related item? All I'm saying is that there ought to be the same options no
> matter how you choose to describe that article.
I guess I wasn't specific enough. Yes, you would describe the article on
its own and use relatedItem to point to the host and the location in the
host in <part>. In other words, the author of the article would be
mods:name and the title mods:title, not under relatedItem.
There are alternatives depending on what you choose to describe, because
if you describe something at a higher level, you can use relatedItem for
its component with type="constituent". (The CD with tracks could describe
the CD as a whole with separate relatedItems type="constituent" for each
track; or could be done as a track with a relatedItem type="host" to link
to the parent if you wanted to do this.)
> > 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
> > area.
> I think that would be great. I cringe at the thought of making MODS more
> complicated. I like its relative simplicity. However the parsing of
> <extent> under <physicalDescription> does, in some ways make things easier
> and not harder. It's difficult to get people who are not MARC catalogers to
> concoct an extent statement without giving them lots of examples and
> guidelines. Much easier to provide the framework that lets them choose the
> appropriate unit and fill in a value. We can do this anyway, in an entry
> form, but it's nice if the form reflects the underlying data structure.
We would entertain a proposal on what people would like to see.
> Ruth Bogan