allow tei:date/@ref

[wenamun]

Context: We are creating a gazetteer for ancient calendar dates (“GODOT - Graph of Dated Objects and Texts”, very preliminary website: https://godot.date) which will mint disambiguating URIs for instances of ancient calendar systems (like e.g. geographic gazetteers do for place names). These URIs hold full canonical calendar information like day and month, but also year & reign of some rulers, the names of eponymous officials like Roman consuls, converted Julian equivalences etc.

In parallel with making use of geographic gazetteers/authoritative lists like geonames, viaf etc. (in placeName/@ref or persName/@ref), we would like to use these disambiguation URIs for dates, but this feature is currently missing in TEI as @ref is not allowed in element <date>.

We are aware that <date> already has a number of attributes (like @calendar, @period, @datingPoint, @datingMethod), but they don’t fit semantically for what the GODOT calendar gazetteer URIs stand for. Furthermore, to cite from TEI documentation, @ref “provides an explicit means of locating a full definition or identity for the entity being named by means of one or more URIs” — this reflects exactly what we want to do. In many cases, date/@ref would be used alongside @calendar, @period etc., each recording a different piece of information or disambiguator about a complex or uncertain dating expression.

Concrete example: https://epigraphy.packhum.org/text/227955 … ἔτει ιεʹ Ἁδριανοῦ Καίσαρος τοῦ κυρίου, ιαʹ Χοίακ. (Year 15 of Hadrian, month Choiak, day 11)

Our immediate need would be to have @ref for <date>, in (simplified) EpiDoc as follows:

… <date ref="https://godot.date/id/some_identifier">ἔτει ιεʹ Ἁδριανοῦ <lb n="7"/>Καίσαρος τοῦ κυρίου, ιαʹ Χοίακ. </date>

Possible Solution(s): Solution #1: adding att.canonical to <date> But: Wouldn’t it make sense to have @ref also in elements like <origDate>, <time> (for the moment GODOT does not deal with time, but this could change in the future), age, birth, death, floruit, etc.?

Solution #2: add att.canonical to all members of att.datable But there seems to be some attribute clash: <birth> and <death> already have att.canonical through att.naming.

We will be totally fine with solution #1, although solution #2 could be a bit more systematically.

[gabrielbodard]

This certainly seems sensible to me, from an EpiDoc perspective. The proposed use of date/@ref is clearly distinct from the other att.datable attributes cited (it wouldn't point to a calendar, dating system or period, but rather to a full definition and identity of the date itself), and it would not be redundant with the dating attributes (especially from att.datable.custom) which might encode some of the same dating information in the XML file itself.

I would vote for Frank's solution no. 1, and add att.canonical only to <date>, not only because of the complexity and potential attribute clash with <birth> and <death> (which are not only dating elements), but more pragmatically because the only use-case offered by the requested is for using this attribute on <date>, i.e. on the tagging of a dating expression in the transcribed text itself, with all the uncertainty and complexity such expressions may bring. I can't foresee recommending in EpiDoc that pointers to GODOT URIs be used in <origDate>, <floruit> or any other such elements, which are generally digested, editorial data, not raw transcription.

One could argue for also including it on <time>, I suppose, especially since GODOT is surely not the only provider of URIs for date and time expressions in the world.

[emylonas]

Assigned to @hcayless so he will notice this ticket. @emylonas can make the change

[sydb]

I am +1 on @gabrielbodard’s position, in favor of putting both <date> and <time> in att.canonical. (I don’t really see any use case for <time>, but since I think of these two elements as the same thing …) But what about <docDate>?

[PietroLiuzzo]

I also like solution 1, but I would really like to have this also for <origDate>!

[hcayless]

Council has discussed this, and we think @ref on <date> is a good idea. We are inclined not to extend it further at this point, but that could certainly be an additional feature request after this is implemented.

[sydb]

I hope, @hcayless , that this means putting both <time> and <date> into att.canonical, no?

[gabrielbodard]

Thanks for confirming this. I would encourage @PietroLiuzzo to go ahead and propose the addition of @ref or att.canonical to <origDate> separately, if he has a concrete use-case for it, but I agree with Council's decision that this is a separate feature request from this one. The use of @ref on <date> as proposed by the Godot projects is for pointing to canonical representations of dating expressions, usually in a text, and this is not what <origDate> records, so the argument would need to be different.

(And a point of clarification re issue tracker admin: does the addition of the [Status:Go] label on this ticket indicate that Council have definitively agreed to implement this as @hcayless described, and it is not in danger of being dropped or altered in further discussed between now and the next TEI release? I would like to know if I can act safely on this assumption… Many thanks!)

[sydb]

Well, yes and no, @gabrielbodard , that’s sort of what [Status:Go] means: That the assignees (@hcayless and @emylonas in this case) are free to go ahead and implement. However, it’s not entirely clear to me what they will actually implement (just @ref on <date>, or both <time> and <date> in att.canonical).

But worse, no, you are not guaranteed that because it’s [Status:Go] that it will actually make it into the next release of the Guidelines. Council can reverse that decision anytime up to release day. That said, this strikes me as a pretty safe one, and I would go ahead and use it (date/@ref) if I were you. (And if you really had to, you can change them to date/@gb:ref and go on with your life; but I very much doubt that would be necessary.)

[hcayless]

I was planning to do it soon. I'm dithering over whether to do <time> as well. I could see it being used in similar ways, but it wasn't asked for, and I think that should usually be the reason why we do stuff.

[gabrielbodard]

@sydb: in brief… because I'm editing EpiDoc here, not my personal schema, the "just use a custom attribute if TEI Council decide to change their mind at the last minute" approach really won't wash. (EpiDoc has a firm dictum that they will always be a valid subset of TEI.) I have made the change in the dev version of EpiDoc, but that's not an official release yet. In the event that we do make our next release before the TEI make theirs, I guess we'd have to take yours and Elli's and Hugh's word for it that it won't change.

Thanks @hcayless for making the commit to TEI code. That echoes what I've done in EpiDoc, and hopefully we'll converge in a few months time.

[PietroLiuzzo]

thanks @gabrielbodard I think then that the problem is (with my understanding of) where to use the GODOT URIs. I was agreeing with @wenamun suggestion that it would actually be useful to have these in <origDate> as well. Given it takes any form of date, we might use that to provide a non converted date of origin of a manuscript as it appears in a colophon and then use the Godot URI there. I will wait to see what the use of GODOT is and if it will be the case to further argue for <origDate>. It is already good that we will possibly be able to use this in <date>, and mark directly in the colophon texts these cases with the Godot URI.

[emylonas]

well, hasn't had any real use cases yet.

On Fri, Nov 23, 2018 at 4:18 AM Pietro Liuzzo notifications@github.com wrote:

thanks @gabrielbodard https://github.com/gabrielbodard I think then that the problem is (with my understanding of) where to use the GODOT URIs. I was agreeing with @wenamun https://github.com/wenamun suggestion that it would actually be useful to have these in as well. Given it takes any form of date, we might use that to provide a non converted date of origin of a manuscript as it appears in a colophon and then use the Godot URI there. I will wait to see what the use of GODOT is and if it will be the case to further argue for . It is already good that we will possibly be able to use this in , and mark directly in the colophon texts these cases with the Godot URI.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TEIC/TEI/issues/1821#issuecomment-441188770, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwP5VbYWhTLmvZc0s7bALTTpzqh6ecqks5ux71-gaJpZM4WsYaF .

[gabrielbodard]

I'm probably (partly) with @PietroLiuzzo here, I think… Although I only have a use-case for @ref on <date> (alongside the GODOT project), I'm not sure I agree with @hcayless and @emylonas that the lack of a use-case for <time> means that we shouldn't consider that at all. Surely consistency and rationality should also be a "reason why we do stuff"? Wouldn't it make sense to align <date> and <time> elements (that only differ in their scale) as closely as possible?

As for <origDate>, I'm a bit less clear. Would @ref on origDate always and unambiguously refer to a standard identifier for the dating expression? Or could origDate contain multiple dating criteria or expressions or other information, which should therefore be defined/identified separately? If the latter, then I might suggest Pietro's use case of copying a manuscript date into <origDate> should be encoded with a <date> element inside origDate, and the GODOT uel sim. URI in @ref on date, instead of origDate. In any case, perhaps this needs a new ticket…?

[gabrielbodard]

Much as I would like to push the case for aligning <time> purely on logical grounds, I now have a concrete use-case for including a GODOT URI in @ref on <time> (an inscription in my corpus that dates an event to "the first hour" of the day prior to the inscribing). @hcayless, is it okay to reopen this request to push for the inclusion of att.canonical in the model for <time> as well as <date>, or should we open a new ticket?

[sydb]

Don’t care if it’s on this ticket or a new one, but I am all in favor of making <time> a memeber of att.canonical.

[emylonas]

closed with c4f8c83