This wasn't intended to be a complete example, but just an illustration of how it could be done-- thus the namespace declaration was missing as was the root <mods> tag.
I apologize for leaving out closing tags for originInfo and part; there should have been 2 closing relatedItem tags as below. So the relatedItem nested under the constituent relatedItem shows you where in the larger work this is found (i.e. the vol number and page numbers).
Example again with added closing tags:
<title>Clitophon, Republic, Timaeus, Critias</title> </titleInfo> <name>
[add additional title/part information for other chapters]
As for nesting relatedItems, my thinking was as follows. If the resource being described is this collection with constituent works, then each constituent has a location within the larger work and that information should be under the description of each constituent. It is a bit difficult to do this example without seeing the context of the parts and how everything is related. But then there are also many other ways to describe this resource (see the comment/question from Carolina Santamarina, which I will comment about separately).
From: Metadata Object Description Schema List [mailto:[log in to unmask]] On Behalf Of Saašha Metsärantala
Sent: Wednesday, December 26, 2012 8:06 PM
To: [log in to unmask]
Subject: Re: [MODS] How to mark chapter/book/multipart monograph/series
Thanks for this example!
Reading it, I noticed a few details, one of which raised a deeper question. I begin with the smaller details:
- The namespace declaration (xmlns) is missing on the root element.
- Three closing tags are missing; the placement of two of them (originInfo and part) may be guessed quite unambiguously.
The placement of the third missing closing tag (relatedItem) is not straightforward though, because the xsd schema validates both consecutive and nested relatedItem elements even when one of them has a @type="constituent" attribute and the other one a @type="host" attribute.
I have used nested relatedItem elements, but never any relatedItem element with a @type="host" attribute nested within a relatedItem element with a @type="constituent" attribute. The schema validates such a construct, but such semantics is unclear. A construct with a relatedItem element with a @type="constituent" attribute nested within a relatedItem element with a @type="host" attribute could possibly be considered useful when the order of the two constituents is unknown, though.
Somewhat similar problems may occur with @type="succeeding" and @type=preceding"" attribute values.
Therefore, I suggest to write a clarifying note (together with at least one example) about this topic in the guidelines at http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#relateditem
or (if it is considered that some of these constructs should be avoided) I suggest to modify the schema to avoid them.