#225 @calendar should be a data.pointer


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.)


  • James Cummings

    James Cummings - 2010-05-13

    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.


  • Lou Burnard

    Lou Burnard - 2010-07-06
    • milestone: --> 871209
  • Lou Burnard

    Lou Burnard - 2010-07-06

    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)

  • Lou Burnard

    Lou Burnard - 2010-09-13

    Proposal is to add some more values to the suggested calendar codes, and point to the W3C list cited below.

  • James Cummings

    James Cummings - 2010-09-14

    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.


  • BODARD Gabriel

    BODARD Gabriel - 2010-09-16

    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.

  • BODARD Gabriel

    BODARD Gabriel - 2011-04-12
    • assigned_to: nobody --> gabrielbodard
    • milestone: 871209 --> 871208
  • BODARD Gabriel

    BODARD Gabriel - 2011-04-12

    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.

  • BODARD Gabriel

    BODARD Gabriel - 2011-04-13

    committed fix to this ticket in SF SVN r8802

  • BODARD Gabriel

    BODARD Gabriel - 2011-04-13
    • status: open --> open-accepted
  • BODARD Gabriel

    BODARD Gabriel - 2011-04-22

    Closing ticket. (Also changing values in Guidelines example to the W3 list James suggests below.)

  • BODARD Gabriel

    BODARD Gabriel - 2011-04-22
    • milestone: 871208 --> AMBER
    • status: open-accepted --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks