Ray,
Good points!

You're right, perhaps it was an overstatement on my part to say TEMPER 
"can handle" non-Gregorian dates.  I guess the point I was trying to 
make is that we need a way to encode, and, ultimately, manage these 
types of dates in our records, and that TEMPER might be a way forward.  
I agree that until there is an established and recognized set of 
calendar codes and formatting conventions, using another format probably 
doesn't make much sense--at least we have display strings now and, if 
we're not careful, in the end we won't even have those.  Of course, 
introducing another date format into the mix also means potentially 
having to sacrifice some interoperability between MODS records in 
general, but I guess these are the expenses that the MODS committee is 
trying to weigh.

Long term, It seems to me that establishing a calendar list would be the 
way to go.  It's a big project because each calendar, as you point out, 
would need to have its own formatting conventions established as well.  
I have no idea how much of this work has already been done, but from a 
data and programming perspective we may be talking about a new set of 
data types for each established calendar.

Also, as an aside, one of the nice things about the established 
date/time formats, such as the XML primitive date and time types, is the 
functions (XPath in this case) that languages make available to 
encapsulate parsing and display formatting.  With other calendars you'd 
likely want to be able do the same, and maybe convert to a Gregorian 
date (or date range) as well.  I think any new date format would be much 
more likely to gain traction if these sorts of helper libraries were 
made available.

-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



Ray Denenberg, Library of Congress wrote:
> 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
>>>