Generic dating class

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?

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.

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

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.

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.

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

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.

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.

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?

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

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!

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.

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!

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.