Hi Laura,
Sorry to take so long to respond
to this – we’ve definitely got this on the list of changes to consider. One of
the things we’d have to decide is if this is a 3.4 change or a 4.0 change.
Thanks,
Jenn Riley
Chair, MODS/MADS Editorial Committee
From: Metadata Object
Description Schema List [mailto:[log in to unmask]] On Behalf Of Akerman,
Laura
Sent: Wednesday, April 01, 2009 4:56 PM
To: [log in to unmask]
Subject: [MODS] Another suggestion: option for more detailed
physicalDescription/extent with measurements and units
I have a feeling this has been suggested sometime ago (maybe
by me); if so excuse the redundancy, but I didn't see it on the list of things
being considered. Extent and a unit attribute got some discussion on this
list back in 2006, according to the archives.
It could be useful to be able to express extent as separate
"object or part measured" "dimension measured", "unit
of measure" and "measurement value" elements or attributes in
MODS. This could be handled several ways; not sure what would work best
or be most compatible with MODS overall, and am hoping some real XML hounds
will look at it and critique/suggest the best ways to go about it.
This is an example of how details about measurements are
handled in VRA Core 4.0, using attributes:
<measurementsSet>
<display>Base 3 cm (H) x 36 cm (W) x 24 cm
(D)</display>
<measurements type="height" unit="cm"
extent="base">3</measurements>
<measurements type="width" unit="cm"
extent="base">36</measurements>
<measurements type="depth" unit="cm"
extent="base">24</measurements>
</measurementsSet> 04/
Not suggesting MODS adopt it wholesale, but how about:
<extent measurementType="height"
unit="cm" value="3" object="base">base
height: 3 cm.</extent>
<extent measurementType="width"
unit="cm" value="36" object="base">base
width: 36 cm.</extent>
etc.
Or just,
<extent measureType="height"
unit="cm" value="22" part="base"/>
More radically (probably would have to wait for 4.0):
<extent>
<measurement>
<measureObject>base</measureObject>
(object could be omitted if extent is for whole item, or use
"whole")
<measureType>height</measureType>
<measureUnit>cm</measureUnit>
<measureValue>3</measureValue>
</measurement>
<measurement>
<measureObject>base</measureObject>
<measureType>width</measureType>
<measureUnit>cm</measureUnit>
<measureValue>36</measureValue>
</measurement>
(etc. for depth)
(Optional: an eye-readable statement. This could also be built from
the measure elements)
<extentNote> Base 3 cm (H) x 36 cm (W) x 24 cm
(D)</extentNote>
</extent>
More tags… but rather than have attributes that would
be flexible because one wouldn't want to try to supply all possible values as
controlled lists(!), make all the measurement factors subelements (with perhaps
an authority attribute so people could define controlled lists if they wanted
to).
Advantages of adding these elements to MODS as options:
measurements can be considered part of "descriptive metadata"
- giving potential users an idea of the dimensions of the item
being described: its running time; how many pages it has;
how big/tall/wide it is; how fine a resolution it
has. But dimensions could also be part of "technical metadata"
that could be useful in a variety of ways to those maintaining the
object. Providing in MODS for more finely-grained extent elements
could allow that level of data to be captured in the descriptive stage and then
also used as technical data.
By separating out the value (number) it could be possible to
perform calculations that would be useful. My own interest in this goes
back many years, and to MARC. I was in charge of a group figuring out how
we were going to handle a large storage shift project. We wanted to sort
the books by height in order to maximize the number of shelves we could have in
our unit. It was quite disappointing not to be able to get any data from
our MARC records because, although the 300 $c followed some patterns that might
have allowed teasing apart the data using "regular expressions", we
didn't have tools to do that at that time, and the data probably wasn't
consistent enough if we did.
Having the measurement detail in extent would also make
things easier when mapping to and from standards like VRA Core that require the
finer grain.
Does anyone else have some thoughts along these lines?
Laura
Laura Akerman
Technology and Metadata Librarian
Robert W. Woodruff Library
Emory University
Atlanta, Ga. 30322
(404)727-6888
This e-mail message (including any attachments) is for the sole use
of
the intended recipient(s) and may contain confidential and privileged
information. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.
If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).