Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#212 Generic dating class

AMBER
closed-fixed
1(low)
2014-01-10
2010-01-03
Ian Rons
No

Currently, there is no elegant or canonical way to specify a normalized representation of a non-Gregorian <date>. @when and @when-iso both use Gregorian, which is fine for recent dates, but for work on (e.g.) pre-17thC sources there is usually no reason whatsoever why one would, or should, convert Julian dates into Gregorian; and in fact this can't be done in certain other cases where there is no accepted mapping to Gregorian, as for instance with ancient dates, or where the date is within a fictional context. However, without a generic normalization attribute for non-Gregorian dates it becomes messy to sort dates. <orig> and <reg> could do it, but are always going to be implementation-specific and are hardly elegant for such a potentially very common task.

I am proposing a general-purpose solution which would provide a very broad range of functionality as described by example below, and which would require a new attribute class under att.datable as follows:

att.datable.generic

@datingPoint [data.pointer, optional]
supplies a pointer to some location defining a named point in time with reference to which the datable item is understood to have occurred. [e.g., points to a taxonomy/category or event.]

@datingMethod [data.pointer, optional]
supplies a pointer to some location defining a calendrical system or other means of interpreting the value of @when-generic, @notBefore-generic, @notAfter-generic, @from-generic or @to-generic (possibly with respect to @datingPoint).

@period [Identical to the attribute in att.datable.w3c.]

@when-generic, @notBefore-generic, @notAfter-generic, @from-generic, @to-generic [data.word, optional]
supplies the value of the date or time in a standard form, e.g. yyyy-mm-dd, which can be an absolute or relative value depending on the presence of the other attributes.

Some examples:

<date when-generic="0027" datingPoint="#RamesesII" datingMethod="#Egyptian365">27 years into the reign of Rameses II, counting in the Egyptian 365-day calendar</date>

On the <date when-generic="5" datingPoint="#ArabianNights">5th night</date>, Scheherazade told another story...

<date when-generic="1590-02-20" datingMethod="#JulianOS">The 20th Feb 1590 (old style)</date> is <date when-generic="1591-02-20" datingMethod="#JulianNS">the 20th Feb 1591 (new style)</date> in the Julian Calendar, according to the English custom.

We aim to sight land on the <date when-generic="35" datingPoint="#sailedSierraLeone" datingMethod="#TravelItinerary">35th day</date>.

In the last example, the targets of @datingPoint and @datingMethod might be as follows:

<taxonomy xml:id="dating">
<category xml:id="TravelItinerary">
<gloss>@when-generic indicates the number of days as an integer.</gloss>
</category>
</taxonomy>
...
<person xml:id="RevRichardMadox">
<event xml:id="sailedSierraLeone" when-generic="193" datingPoint="#sailedSouthampton" datingMethod="#TravelItinerary"><label>sailed from Sierra Leone</label><p>This was 193 days after leaving Southampton.</p></event>
...
<event xml:id="sailedSouthampton" when-iso="1582-01-01"><label>sailed from Southampton</label></event>
</person>

In addition to the above class att.datable.generic, it would be greatly advantageous if @calendar were available as part of att.datable. Currently, it is only available for <date>, although there seems no reason why this should be the case. It should be emphasized that it specifies the calendar system of the text within the given element rather than that of the attributes of the @when genus, to avoid confusion; however, in the absence of @datingPoint and @datingMethod it could, by convention, indicate the calendrical system used by @when-generic, e.g.
<date when="1499-12-23" when-generic="1500-01-01" calendar="Julian">1st Jan 1500</date>
<date when="1499-12-23" when-generic="905 Jumada i-Ula 11" calendar="Islamic">905 Jumada i-Ula 11</date>

As an aside, after discussion in the TEI-MS-SIG List, it seems likely that some people are currently using @when for Julian dates without realising that they are meant for Gregorian dates. It would be helpful to specify this in the attribute <desc>, which is currently rather misleading. Alternatively, @when might be renamed @when-w3c.

Related

Bugs: #635

Discussion

  • Martin Holmes
    Martin Holmes
    2010-01-11

    My initial reaction to this is positive, and it would provide a potential solution to a problem we've been facing with regard to integrating vague, but "real", dates of events in the ancient world, and equally vague, but fictional, dates of mythological events. In particular, we have noted inconsistent chronologies (where event A is reported to have happened before event B, and event B before event C, while another source, or even the same one, specifies C as having happened before A.

    However, I'm not really sure I understand exactly how @when-generic and its friends are supposed to work. It can be relative or absolute -- which is excellent, and would cover the above scenario by allowing us to specify dates of events relative to each other, without worrying about whether there are logical inconsistencies -- but I'm not sure how to express these relationships. Would the content of @when-generic be constrained in some way, or would its content form be documented somewhere else? I could imagine using <date notAfter-generic="#eventADate" notBefore="#eventBDate"> to specify the date relationship for event C; I could also imagine relative time periods (the day after, a month before) and so on. Would the usage of @*-generic be documented in the <event> element pointed to by @dating-point?

     
  • Ian Rons
    Ian Rons
    2010-01-11

    Good points.

    Re: whether the content of @when-generic would be constrained, I think the best way to approach it would be to leave it up to the user whether or not to enforce rules (by Schema or Schematron), though if adopted, I think the Guidelines ought to recommend (for instance) using the same kinds of patterns as for @when-iso or even @when (easy for Julian dates, for instance); however, the idea is to be as flexible as possible, so basically the only constraint is that it's a data.word (rather than a data.pointer).

    Re: your second point, the example you give,
    <date notAfter-generic="#eventADate" notBefore="#eventBDate">
    is actually something I hadn't envisaged -- I was thinking of @*-generic as a number/string, not a pointer. My scheme as currently outlined allows for one free-text "date" (i.e., @datingPoint) and one or more *numerical* offsets, so what you suggest is a departure, but I don't see why you couldn't use pointers, and even though it's pretty self-explanatory you could and probably ought to describe what you're doing with @datingMethod (not @datingPoint), so it might look like this:

    <event xml:id="eventC" notAfter-generic="#eventA" notBefore="#eventB" @datingMethod="#describeUseOfPointersIfPedantic">

    However, I suspect the semantic purists might object to the dual use of @*-generic as both number/word-like and pointer-like. It would be pretty handy though.

    The use of pointers in @*-generic would be mutually exclusive to the use of @datingPoint (since pointers point to definitions of dates that are by nature "atomic", and therefore don't relate to @datingPoint), which is perhaps more of an issue, but this could be explained in the Guidelines I suppose.

     
  • Syd Bauman
    Syd Bauman
    2010-01-11

    > However, I suspect the semantic purists might object to the dual use of
    > @*-generic as both number/word-like and pointer-like. It would be pretty
    > handy though.

    I’m not sure I qualify as any kind of purist, but as a pragmatic programmer, it seems it would be potentially impossible to differentiate pointer cases from number/word-like cases. Remember, "2010-01-11" is a valid relative URI.

     
  • Ian Rons
    Ian Rons
    2010-01-11

    True, so perhaps @datingMethod should be a required attribute? Then it wouldn't be necessary to guess how to interpret the attributes. Is there, then, any reason to prevent the use of pointers in @*-generic? That would seem to give the generic dating class a very comprehensive scope, so it's very tempting.

     
  • Lou Burnard
    Lou Burnard
    2010-02-01

    When the current facilities for date normalization were discussed, it was agreed that the TEI should offer just one way of normalizing dates, and that this should be based on existing standards. There was dome debate (which continues) about whether we should adopt the full range of date representations provided by ISO 8601 or just the subset of that implemented by W3C. The decision was to support both; so we have both (e.g). @when-w3c and @when-iso. To make life easier, we define @when as equivalen to t @when-w3c rather than @when-iso (though some folks would like us to rethink that). Note that in either case though, we're talking about *representations* of date/time values in a single calendar. These attributes won't help you express the arcana of other calendar systems; it's not what they're for. They express points in time using just one method, and that's all they aim to do. So yes, if you want to express normalised versions of your non-Gregorian dates you will either have to work out how to convert them into Gregorian dates (not always as difficult as all that), or you will have to propose another method of normalizing them. If you take the former approach, you can still structure your date internally using whatever method you care to invent in order to show that this date in the XXX calendar is the fourth Skramaloon of the Fifteenth Dingbat in the year of the dog (if that';s your bag) , but you can now compare that date with other events using other calendars ("is this date before or after the 124th July 1789"). Which is the purpose of normalization. Alternatively, if you take the other approach, your encoding may well look a lot simpler, but now you can do date comparisons only with other Dingbat lovers,

    So, I think there's a lot to be said for discussing how we might organize the internal structure of a date in a non-Gregorian calendar, but I think that should be done quite independently of the question of how that date value should be normalised. For better or worse, we measure normalised times in terms of the Gregorian calendar, just as we measure space using the metric system and inventing another way would be, in my opinion, an otiose and retrograde step.

     
  • Lou Burnard
    Lou Burnard
    2010-02-01

    • assigned_to: nobody --> sbauman
     
  • Ian Rons
    Ian Rons
    2010-02-03

    > When the current facilities for date normalization were discussed, it was
    > agreed that the TEI should offer just one way of normalizing dates, and
    > that this should be based on existing standards.
    That’s fine, and as it should be I think, but there is of course a difference between _offering_ a specific method of normalization and _allowing_ other methods of normalization. @when and @when-generic are not mutually exclusive.

    > So yes, if you want to express
    > normalised versions of your non-Gregorian dates you will either have to
    > work out how to convert them into Gregorian dates (not always as difficult
    > as all that), or you will have to propose another method of normalizing
    > them.
    I don’t think it’s that simple. I’m not proposing another method of normalization (e.g., some Chinese dating standard) be offered by the TEI, merely that there be a standard way to include non-Gregorian machine-readable date strings in a per-project (or wider) setting. Currently, one can use <reg>, but this is idiosyncratic and verging on tag abuse (to use what is meant for human-readable text to enclose what is intended as a solely machine-readable string).

    It’s clear there is a fairly large set of dates that don’t play nicely with Gregorian, but which still need to be normalized in some way. See the discussion at TEI-MS-SIG for examples which I omitted to provide a link for in the feature request, beginning here:
    http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0912&L=TEI-MS-SIG&T=0&P=442
    but note particularly this one re: Egyptian dating and dates in fictional literature:
    http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0912&L=TEI-MS-SIG&D=0&T=0&P=904

    > Alternatively, if you take the other approach, your encoding
    > may well look a lot simpler, but now you can do date comparisons only with
    > other Dingbat lovers
    “Dingbat lovers” might encompass an entire discipline.

    > So, I think there's a lot to be said for discussing how we might organize
    > the internal structure of a date in a non-Gregorian calendar, but I think
    > that should be done quite independently of the question of how that date
    > value should be normalised.
    I’m not sure exactly what you mean here, but if I read you right then I agree that the internal structure of a non-Gregorian date string is a separate matter; but again, I am not proposing any specific method of normalization, but a container for a normalized string.

    > For better or worse, we measure normalised
    > times in terms of the Gregorian calendar, just as we measure space using
    > the metric system and inventing another way would be, in my opinion, an
    > otiose and retrograde step.
    Unfortunately, humanists insist on working with texts that were created before the metric system was invented, which presents similar problems, for instance with Egyptian “royal cubits”, which have no metric equivalent. The assumption that the number of people wanting to use such “Dingbat” measures will be vanishingly small might be self-fulfilling if such Procrustean standards are insisted upon.

     
  • Ian Rons
    Ian Rons
    2010-03-08

    I was slightly bemused by the discussion of this feature request by the Council.
    http://www.tei-c.org/Activities/Council/Meetings/tcm44.xml

    If the minutes are anything to go by, it would seem that the meaning of this feature request has been seriously misunderstood. It has nothing whatever to do with ISO or W3C standards (which both use Gregorian) at all.

    I trust, in the light of this, that this feature request can again be raised again at the next Council meeting.

     
  • Lou Burnard
    Lou Burnard
    2010-04-30

    • assigned_to: sbauman --> louburnard
     
  • Lou Burnard
    Lou Burnard
    2010-04-30

    Council agrees that providing an alternative system of normalisation is desirable, but has reservations about the proposed implementation, e.g. concerning the datatype of the proposed attributes.

     
  • Syd Bauman
    Syd Bauman
    2010-04-30

    I'm afraid I hadn't noticed this discussion until now. I think the overall idea of att.datable.generic is a great one. I have to slog through the details a bit more, but I find myself wondering how much this functionality overlaps with that of <timeline>. In the meantime it occurs to me that @period should be moved from att.datable.w3c to att.datable, no?

     
  • Martin Holmes
    Martin Holmes
    2011-04-12

    Outcome of the council meeting discussion on 2011-04-12:

    We see the use-case and agree it needs to be served. Our final proposal is below, following a report on the discussion we had.

    We discussed the possibility that we might need to distinguish between "standard" dating systems (such as the Islamic calendar) and "fictional" systems (such as the Star Trek calendar), but decided that this is not a meaningful distinction; all calendar systems are essentially fictional.

    We discussed the proposal by Lou that all of this should be handled through the creation of a specialized element, but determined that this would be inadequate, because the requirement is to supply custom dating features for all the elements in att.datable, and to allow these to co-exist beside standardized dates expressed using the existing attributes.

    Therefore we believe that there is a need for these attributes. However, we are unhappy with the use of "generic", since we believe this would be misleading; we would prefer "custom", because this would tend to discourage the accidental use of these attributes by someone who didn't really understand the difference between the various sets of dating attributes.

    We like the @datingPoint and @datingMethod, as data.pointer, and suggest that the latter could be used (and should probably be shown in the guidelines) to point to the <calendarDesc> element which will probably arise out of ticket #2994671.

    So:

    The following attribute class should be created:

    att.datable.custom

    It should be added to att.datable, alongside att.datable.w3c and att.datable.iso.

    The following optional attributes should be added to the class, with a datatype of 1-to-infinity of data.word:

    @when-custom
    @from-custom
    @to-custom
    @notBefore-custom
    @notAfter-custom

    The following optional attributes should be added to the class, with a datatype of data.pointer:

    @datingPoint
    @datingMethod

    In addition:

    @calendar should be moved from att.date to att.datable.
    @period should be moved from att.datable.w3c to att.datable.

    Finally, a new section needs to be added to the Guidelines to explain the use of these attributes. This can only be accomplished once action has also been taken on ticket #2994671 (<calendarDesc>). In the meantime, we should be collecting some plausible and real examples that demonstrate the variety of possible uses, building on what the submitter has already provided. I would suggest that we include examples from the Islamic calendar, at least one ancient calendar (Egyptian?), one Julian (preferably one not easily normalized to Gregorian), and one more obviously fictional (Star Trek?).

     
  • Lou Burnard
    Lou Burnard
    2011-04-15

    I dont think I ever proposed that "all of this should be handled
    through the creation of a specialized element" -- my proposal was to limit the damage by adding these proposed new attributes to <date> only, and then requiring those who wish to use them elsrewhere to do so by embedding a <date> within the datable element concerned. Not pretty, I agree, but perhaps less unpretty than you make it sound here!

     
  • Ian Rons
    Ian Rons
    2011-04-16

    Although I'm not involved with TEI encoding these days, nevertheless since I submitted this request I'll just put in my twopence-worth.

    The original request did not consider how @calendar might be affected by the addition of @datingMethod. There is something of an overlap between the functions of these two attributes, and a very serious risk of confusion as to what these two attributes relate to. The former is an enumerated value which refers to the element text, the latter is proposed as a pointer to <calendarDesc>. I suspect a survey of TEI usage might reveal that @calendar has, effectively, been used as a substitute for @datingMethod, with encoders supposing it relates to @when, etc. It might be preferable if @calendar became a data.pointer, to conform with @datingMethod.

     
  • BODARD Gabriel
    BODARD Gabriel
    2011-11-07

    • assigned_to: louburnard --> gabrielbodard
     
  • BODARD Gabriel
    BODARD Gabriel
    2011-11-25

    • status: open --> pending-accepted
     
  • BODARD Gabriel
    BODARD Gabriel
    2011-12-08

    All done, but probably not documented as fully in the prose guidelines as it should be. I haven't had time to do this last yet, and shan't in the next few days. If someone else would like to do so before the new release is launched, please be my guest!

     
  • James Cummings
    James Cummings
    2013-11-19

    • assigned_to: BODARD Gabriel --> Hugh A. Cayless
    • Priority: 5 --> 1(low)
     
  • James Cummings
    James Cummings
    2013-11-19

    Reviewing at 2013-11 Oxford Face-to-face HC to double-check whether it’s actually been done, add documentation/examples to guidelines. MH offered examples if needed.

     
  • Explanatory prose in the Guidelines section of Dates and Times was never written [bugs:#635] opened to address that. Closing.

     

    Related

    Bugs: #635

    • status: pending-accepted --> closed-fixed