Date:         Wed, 14 Nov 2007 11:22:34 -0500
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         "Rebecca S. Guenther" <[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: TEXT/PLAIN; charset=US-ASCII

The biggest problem here is the fact that ISO 8601 defines a bunch of
alternatives and representations and it is difficult to specify what
portions of ISO 8601 you are using. In MODS we have enumeration values
"w3cdtf" and "iso8601" and we specifically define what we mean when we say
the encoding is "iso8601" to distinguish it from what "w3cdtf" means
(since the latter also is compliant with and a subset of
8601). The purpose of the guidelines was to say that we are using
what is called the "basic" form in ISO8601 (i.e. the form without
the hyphens, which is YYYYMMDD etc.) rather than the "extended" form,
which is the form with hyphens (YYYY-MM-DD) as specified also in W3CDTF.
 
Although I am not an EAD expert, it looks like EAD also specifies
particular constructs from ISO 8601 and is using the date range as
specified there. In your case you want to use the date range construct
from 8601, which is specified in EAD. That is represented as a date with a
slash and another date. In MODS we parse the start and end dates into
separate elements (as you noted below). So in EAD it might look like
1999/2000 and in MODS it would be <dateIssued encoding="iso8601"
point="start"> (or whatever date type you have). I can understand why you
don't want to have to parse these. I see no reason why we can't say that
your form is also iso8601 and fix the guidelines to say it is anything
allowed by ISO 8601 using the basic rather than extended form (where this
is applicable). In the case of W3CDTF you would use xs:date as specified
in XML schema that restricts it to the form with the hyphens if you want
it to validate. Using "iso8601" doesn't place such a restriction on the
data, so changing the guideline would not be a big deal and our intention 
was not to restrict it so much. 

Note that we (our office at LC) are trying to work on this problem and
come up with some other profile of ISO 8601 that can be used with various
XML formats, including MODS and PREMIS. That will include being able to
use the basic 8601 format without hyphens, and to deal with questionable,
open date ranges, BCE dates, etc.-- and have a name to call these sorts of
encodings. We know we can't fix the problems with ISO 8601 but if we can
define a different profile and then extend it to accommodate other sorts
of dates, we would all benefit.

Rebecca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^  Rebecca S. Guenther                                   ^^
^^  Senior Networking and Standards Specialist            ^^
^^  Network Development and MARC Standards Office         ^^
^^  1st and Independence Ave. SE                          ^^
^^  Library of Congress                                   ^^
^^  Washington, DC 20540-4402                             ^^
^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
^^  [log in to unmask]                                          ^^
^^                                                        ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Tue, 13 Nov 2007, Riley, Jenn 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
>