Dear Richard,

The MODS/MADS Editorial Committee does have the change you cite from the
older listserv message on its list of requested changes. We'd slotted it
for a 4.0 (rather than the 3.4 minor release issued in 2010) due to the
change in data type of <extent> being non-backwards compatible. I do see
that while in 3.4 we harmonized the definitions of elements that appeared
in multiple places in the Schema we allowed <extent> to remain an
exception to that practice, so we could have just added @unit to <extent>
at that point. This slipped through, though, as we'd already put that
change in the 4.0 queue. Please accept our apologies for not revisiting
the @unit proposal on the table in light of our decision to not make
physicalDescription/extent match part/extent.

The MODS/MADS Editorial Committee is currently in the very early planning
stages of MODS 4.0, the next major release version. We're taking our time
with this, as we're looking carefully at how to define MODS as a more
formal data model rather than only an XML encoding. This would (among
other things) have an effect of making it more SemWeb/Linked Data
friendly. We're also working on how to make this process more open and
transparent, so please stay tuned for more information on that front.

We hadn't planned on issuing another minor 3.x release, but it's becoming
increasingly clear that a more formal data model for MODS 4.0 is a pretty
big undertaking, so we will have to be cognizant of needs that arise in
the meantime that could be addressed in a minor release version. I've made
a note in our list of requested changes about the more lightweight option
so if we do end up looking at a 3.5 release we could get this in.

In the meantime, and speaking only for myself here, it would help me to
hear more about your use case. I do of course see the inherent
attractiveness and potential of making this element into more structured
data. (And I hope a more formal data model for MODS 4.0 would go a long
way towards this.) However, the Editorial Committee has found it helpful
to work from actual real-world use cases, as you can imagine it's pretty
difficult to design around all theoretical possibilities. Can you tell us
more about what you're trying to do? You mention the Zotero MODS exporter
- are you pushing data from a format that does have units as a data
element into MODS? Is there a specific target for this MODS data in mind,
or is it a desire to have as granular an export as possible for
(unspecified) downstream applications?

Thank you!

Jenn Riley
Chair, MODS/MADS Editorial Committee

--------------------------------
Jenn Riley
Head, Carolina Digital Library and Archives
The University of North Carolina at Chapel Hill
http://cdla.unc.edu/
http://www.lib.unc.edu/users/jlriley

[log in to unmask]
(919) 843-5910





On 7/26/11 2:21 PM, "Ray Denenberg, Library of Congress" <[log in to unmask]>
wrote:

>From: Richard Karnesky
>>   http://listserv.loc.gov/cgi-bin/wa?A2=ind0610&L=MODS&P=R2275&I=-3
>> for example.
>
>
>Ok, thanks. Looking at that message, it suggests:
>_________________________________________________________
>You just have to change the definition of <extent> under
><physicalDescription> from
>
><xsd:element name="extent" type="xsd:string"/>
>
>to
>
><xsd:element name="extent" type="extentType"/>
>
>like it is defined under <part>.
>____________________________________________________________
>
>Unfortunately that was not something that could have been done with a
>minor
>release -  e.g. 3.2 to 3.3 - it would have required a major version
>change,
>because it would change the existing definition from a simple string to a
>structured element with subelements.
>
> But the suggestion to simply add a unit attribute to  extent under
>physicalDescription would be possible with a minor version change. I'll
>pass
>that suggestion along to the Editorial Board.
>
>--Ray