Print

Print


Hi Jon -

The Temper draft does recognize the Non-Gregorian requirement. Temper does 
mention Non-Gregorian Calendars while EDTF does not.

However the Temper section on non Gregorian Calendars, section 1.3 in the 
most recent draft (that I can find) - August 2007, 
http://tools.ietf.org/html/draft-kunze-temper-01 -  mostly covers BCE dates. 
And EDTF does provide full support for BCE dates and does so in a manner 
compatible with ISO 8601 (while Temper's approach is not compatible with 
8601). In any case BCE dates is normally not the issue when discussing 
non-Gregorian calendars.

Aside from BCE support though, the only non-Gregorian support Temper offers 
is to reserve all 3-letter codes for future use to indicate calendar 
(Hebrew, Chinese, Islamic, etc.)  It does not actually recognize any 
specific codes, because they don't exist.

In fact, in early drafts of EDTF there was (roughly) similar support for 
non-gregorian dates, but the conclusion was drawn that that level was next 
to useless and that it was too hard a problem to solve, at least in the 
first version.  It's a two level problem: first, to indicate what calendar, 
and second, to represent the date in the proper format for that calendar. 
Obviously we aren't trying to solve the second problem, but even the first 
doesn't lend itself to solution without some recognized vocabulary of 
calendar codes.

Nevertheless, Temper is to be applauded for at least recognizing the 
problem.  Note that EDTF is still a work in progress and if you have 
suggestions on how to approach this problem they would be very welcome. 
EDTF can certainly reserve a three-letter field for calendar code, if that 
would help.

--Ray


----- Original Message ----- 
From: "Jon Stroop" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, July 24, 2009 10:30 AM
Subject: Re: [MODS] temper date format in MODS


> Jenn,
> I'm not very familiar with TEMPER, but as far as I know it is the only 
> format under consideration that can handle non-Gregorian dates (EDTF does 
> not, correct?).  This has been a problem for us for a while, and though 
> TEMPER (or any other format) doesn't automatically solve problems of 
> interoperability with other calendars that may arise, having a way to 
> encode the data would certainly be a start.
> -Jon
>
> Jon Stroop
> Metadata Analyst
> C-17-D2 Firestone Library
> Princeton University
> Princeton, NJ 08544
>
> Email: [log in to unmask]
> Phone: (609)258-0059
> Fax: (609)258-0441
>
> http://diglib.princeton.edu
> http://diglib.princeton.edu/ead
>
>
>
> Riley, Jenn wrote:
>> Dear MODS implementers:
>>
>> There is a proposal in front of the MODS/MADS Editorial Committee to add 
>> the EDTF date format <http://www.loc.gov/standards/datetime/> to the list 
>> of values for the encoding attribute in the MODS date elements. This has 
>> led the Editorial Committee to think about other date formats used in our 
>> community that MODS might need to implement. One that comes to mind is 
>> the TEMPER spec (<http://www.cdlib.org/inside/diglib/ark/temperspec.pdf>, 
>> <http://tools.ietf.org/html/draft-kunze-temper-01>). We understand some 
>> revision/maintenance of TEMPER is happening, although not very publicly 
>> so it is a bit unclear at this time if institutions are considering 
>> TEMPER a viable date format to use. Are any MODS implementers using 
>> TEMPER at this time or have plans to? Is it necessary or desirable for 
>> MODS to add "temper" as a value for the encoding attribute on date 
>> elements?
>>
>> Thank you,
>> Jenn Riley on behalf of the MODS/MADS Editorial Committee
>>
>> ========================
>> 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
>>