I apologize for being a bit thick. But I am trying to understand how to
apply any of this to what I am working on.
Would using the set ups as described below mean keying in this data in
these elements as well as the standard mods fields? I do not want to have
to key in the same sort of data in more than one place.
I want to pull the citation information out with something like a style
sheet of sorts from the data that is there.
So I don't want a separate area to plug in the information but to parse it
out of the basic data so it can be picked and pulled as needed.
The first option below seems good but I really don't understand the
<subDoc> field that surrounds it.
The second one I don't quite understand where it would fit in since Rebecca
points out that some of the information will come from the full record but
other citation information will come from this sub area (?). The information
stored there isn't (in my view) a relatedItem but the item itself.
And, yes, apparently I am confused about the term part or partDescription.
Could those fields be used under the <titleInfo> for the piece so that the
information can be pulled by some sort of request and formatted following
some style standard?
>>> [log in to unmask] 05/05/03 04:52PM >>>
We have had a discussion for some time about citation details that need to
be included in MODS records. As I've mentioned we are planning to revise
the schema soon to include this. I would like some feedback about what we
want to use as names for these elements. Here are some options:
1. Karen's original proposal called for <subDoc>. I wasn't sure that this
was a term that had a whole lot of meaning, but here's what it might look
Attributes: type, order
type: Suggested values: part, volume, issue, chapter
(other values might be included for other types of material, e.g. legal,
which has been recently discussed)
order: Hierarchical order of numbered elements (level of
Use only if different than title of resource being described in
Type: suggested values: pagination, total pages
<date> (uses dateType)
Attributes: encoding, point (keyDate makes no sense here)
Could use dateType to allow for structured and unstructured forms. Use
only if different from date of resource being described in <originInfo>
<text>Textual form of partDesc
We think of these as citations, although a citation also includes what is
in the body of the record, e.g. title, author, etc. So an alternative
might be to call it "citationInfo", recognizing that it is not by itself
the full citation.
So, the below does not include the attributes and all the details as in
the option above, but it would be the same except for the name of the
first element in this group.
3. Call it <partDesc>, which Bruce d'Arcus recently suggested.
This makes some sense, except that the recent exchange of messages started
by Suzanne Pilsk about title and their parts (which I haven't yet had a
chance to respond to-- sorry) shows that there is some confusion about
what to do with "parts", so perhaps it adds to the confusion to call it
Any thoughts or convincing arguments for one over another?