Date:Tue, 13 Nov 2007 15:45:31 -0700
Reply-To:Metadata Object Description Schema List <[log in to unmask]>
Sender:Metadata Object Description Schema List <[log in to unmask]>
From:Joe Altimus <[log in to unmask]>
Subject:Re: date encoding
Comments:To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:<[log in to unmask]>
Content-Type:multipart/alternative;
I see the need to map date ranges too, so it would be useful if the MODS
ISO8601 attribute accommodated that.
Joe Altimus
Arizona State University Libraries
On Nov 13, 2007 1:24 PM, Riley, Jenn <[log in to unmask]> wrote:
> Hi all,
>
> 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?
>
> Thanks!
>
> Jenn
>
> ========================
> Jenn Riley
> Metadata Librarian
> Digital Library Program
> Indiana University - Bloomington
> Wells Library W501
> (812) 856-5759
> www.dlib.indiana.edu
>
> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
>
