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

[log in to unmask]

 

 


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).