I see the need to map date ranges too, so it would be useful if the MODS ISO8601 attribute accommodated that.
Arizona State University Libraries
I'm doing some mappings from item-level EAD inventories into item-level MODS records, and I've run into a problem with date encodings. My source EAD conforms to the EAD2002 XML Schema, which means all @normal attributes on dates are ISO8601. But the MODS date encoding attribute value of iso8601 is described in the User Guidelines < http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html> as *only* the YYYYMMDD format, rather than any valid ISO8601 value, such as 1999/2000 for a date range. I know MODS has other mechanisms for date ranges, but I don't think that in this case implementing parsing of the EAD @normal attribute on dates to look for slashes and convert those into MODS-style ranges is getting enough benefit for the effort it would take. Is it really the intention for the MODS date encoding attribute of the value iso8601 to *only* refer to the YYYYMMDD pattern, and to no other valid ISO8601 encoding? If I've got ISO8601 but I can't guarantee it's YYYYMMDD, am I doomed to leaving the encoding attribute off the MODS date entirely?
Digital Library Program
Indiana University - Bloomington
Wells Library W501
Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com