Menu
▾
▴
#225 @calendar should be a data.pointer
closed-fixed
5
2011-04-22
2010-04-30
No
I think the @calendar attribute should be changed from data.enumerated to data.pointer similar to the @period attribute. This will allow pointing to definitions of the calendaring system in use. This would be much more powerful than an enumerated list and especially give a method for fully document non-standard calendaring systems (such as fictitious calendaring systems.)
While I would prefer that @calendar become data.pointer, if it does not I think the suggested values should change. These should change to those that the W3C suggest in XPath of:
====
Designator Calendar
AD Anno Domini (Christian Era)
AH Anno Hegirae (Muhammedan Era)
AME Mauludi Era (solar years since Mohammed's birth)
AM Anno Mundi (Jewish Calendar)
AP Anno Persici
AS Aji Saka Era (Java)
BE Buddhist Era
CB Cooch Behar Era
CE Common Era
CL Chinese Lunar Era
CS Chula Sakarat Era
EE Ethiopian Era
FE Fasli Era
ISO ISO 8601 calendar
JE Japanese Calendar
KE Khalsa Era (Sikh calendar)
KY Kali Yuga
ME Malabar Era
MS Monarchic Solar Era
NS Nepal Samwat Era
OS Old Style (Julian Calendar)
RS Rattanakosin (Bangkok) Era
SE Saka Era
SH Mohammedan Solar Era (Iran)
SS Saka Samvat
TE Tripurabda Era
VE Vikrama Era
VS Vikrama Samvat Era
====
This is a much more reasonable and internationalised list of calendars than our current list. It comes from a little ways down in http://www.w3.org/TR/xpath-functions-11/#lang-cal-country
But that said, I still think a pointing mechanism is more powerful.
-James
I am not sure what element the pointer should point to if it becomes a pointer. Happy to add some more exotic examples to the suggested valList though. (This FR seems to relate to both the one about culture specific ways of recording personal age and the one about non-standard ways of normalising dates: probably all three should be looked at together)
Proposal is to add some more values to the suggested calendar codes, and point to the W3C list cited below.
If @calendar were a pointer I think that it should point to the same kind of place that @period does. i.e. to a predefined taxonomy in the header, another file with such a taxonomy or the wikipedia article on that calendaring system. These two attributes aren't really that different, except that one is discussing the period of a date and the other the calendaring system in use.
As I state below I think we should AT LEAST provide default values of the W3C suggested codes.... but I still think a more powerful mechanism would be to allow the attribute to be a pointer to a user-defined taxonomy or other URI. The benefit of this is it would allow people to express that a date is recorded in a calendar system (like say Jalali) that the W3C hasn't noticed because of its historical nature. They could point to a taxonomy or say http://en.wikipedia.org/wiki/Iranian_calendars#Medieval_era_:_Jalali_calendar as a form of documentation. This would also allow fantastical calendars like <date calendar="http://en.wikipedia.org/wiki/Stardate">30620.1</date> from things like Star Trek, but also any other calendaring systems we have not already suggested. My argument is that this is better than just a random, undefined, <date calendar="stardate">30620.1</date>. (If it was a URI this could be <date calendar="#stardate">30620.1</date> for example.)
Updating the list of suggested values to at least the W3C recommendation is a must if and only if the calendar attribute isn't changed to a pointer which is a much more useful mechanism.
-James
I agree that a pointer which is able to point to an (internal) taxonomy or an external uri authority for a calendar type would be more useful than a simple enumerated list. There are literally dozens if not hundreds of calendar systems in use in the Greek and Roman period, and I'd rather the job of enumerating them be done somewhere else in the Semantic Web rather than in my teiHeader.
Council decision is to approve the change of datatype of @calendar on <date> from data.enumerated to data.pointer.
In addition, however, we need to create a new calendarDesc element in the teiHeader for this pointer to point to (if no external taxonomy or vocabulary is available). See ticket #3285473 for this feature request.
committed fix to this ticket in SF SVN r8802
Closing ticket. (Also changing values in Guidelines example to the W3 list James suggests below.)