Dear Jenn,
Sorry for taking up such an old posting. We are still working on our MODS implementation and with MODS <> Zotero conversion, this time with Multilingual Zotero.
I would like to ask whether there is any way we can learn which changes are contemplated for version 4.0? You mention in the posting that a number of things are already queued up and it would be very nice if we could take these into account already now.
Regards,
Jens
On Aug 1, 2011, at 3:35 PM, "Riley, Jenn" <[log in to unmask]> wrote:
> 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
|