sorry for the late response. Your question brought up a few issues that we discussed at the MODS Editorial Committee. @unit appears both under <physicalDescription><extent> (where it is defined as a string) and under <part><extent><start> and <end> as well as <total>. Again, under <start> and <end> it is simply defined to be strings. Under the subelement <total> however, it is defined as xs:positiveInteger with the intention of making it machine processible. So in this case, we need to make sure that the value of @unit is understood.
Therefore we are recommending to normalize the name of the unit to the spelled out plural form, because that would semantically make the most sense for values recorded in part/extent@unit=""/total.
The XSLT would be updated accordingly to produce an output that would (for example) look like this:
In this example only <total> will be machine processible, that is the machine will know that there are 12 pages, but it won't understand the range.
The documentation will also be updated to make sure all examples will match the output.
Would that address your issue?
on behalf of the MODS Editorial Committee
Melanie Wacker Metadata Coordinator Original and Special Materials Cataloging Columbia University Libraries New York, N.Y. (212) 854 9676
we are developing a MODS institutional repository (called MIR) that is used in several instances now in Germany. Recently we ran into an import issue.
produces this output inside <part>:
while the user guide (https://www.loc.gov/
standards/mods/userguide/part.) on the other hand suggests html
You see there is a difference between „page“ and „pages“. During development we try to stay close to the documentation and the supplied examples in case of uncertainty. Others data provider seem to stick with your XSL files when exporting to MODS. It would be nice to get this unit type clarified somehow to improve interoperability.
Thüringer Universitäts- und Landesbibliothek
Phone: ++49 3641 940027
FAX: ++49 3641 940022