@calendar should allow multiple values

[martindholmes]

@calendar is currently configured as a single pointer, but actual source texts often combine multiple calendars in a single expression, so it would be helpful if multiple pointers could be used. This discussion on TEI-L:

http://tei-l.970651.n3.nabble.com/Multiple-values-for-calendar-in-the-same-lt-date-gt-element-td4032839.html

covers the issue in detail. Points for and against are made in the discussion. There are no implications for the Stylesheets, which only reference @calendar in tests.

[tillgrallert]

This is just to say that I support the feature request based on the arguments made on TEI-L.

[cthomasdta]

This is just to say that I support the feature request based on the arguments made on TEI-L.

I support it, too, as I have explained in detail in the thread referenced by Martin above.

[lb42]

I OTOH think this change is both unnecessary and potentially confusing. But I am used to being outvoted!

[PonteIneptique]

I am not much in the community but I actually agree with @lb42 : I feel like this change will create some readability issue (The date being at the same time Gregorian and Julian). I am still confused about why a nested tag would be that awful. It would not require to identify two dates, just identify the variation inside the first date.

To take another example in what I feel would be a similar issue, although not exactly the same:

         <p>I found <w lemmaRef="#his #my">his (my)</w> gift</p>

Wouldn't it be weird ? And to me, this discussion on @calendar pushes in this direction...

[tillgrallert]

@PonteIneptique 's comparison and example is misleading in my opinion. First, the encoding of two words in a single <w> seems like tag abuse and, second, "his" and "my" do not refer to the same lemma. On the other hand, the original examples provided by @cthomasdta did indeed refer to a single date expressed by using two calendars in the form of "Tuesday 7/19 May". So wrapping it in a single <date> node makes a lot of sense to me, i.e.

<date>Tuesday 7/19 May</date>

How one marks up the content of this single date node with a combination of child elements and attributes is up to one's preferences and it seems to me that TEI-L agrees on that point.

The actual disagreement is solely over the content of @calendar and @lb42's core argument, beyond disputing that interpretation as a single date, seems to be that if there are more than one calendar present in @calendar one would have a hard time automatically parsing the content of the <date> note for normalisation purposes. But this is not the function of @calendar according to the guidelines.

[PonteIneptique]

I understand the idea that my example might be misleading, I might have not been good at defending it. But to me, here, I would actually argue that there is one "moment" but two dates, the same way you see two different words/two different lemma. Hence proposing:

<date calendar="#A" when="0000-00-00">Tuesday 7<date calendar="#B">/19</date> May</date>

to clearly differentiate both.

[PFSchaffner]

I'm sure this is a source of embarrassment to him, but as usual I am inclined to agree with Lou on this one, including (in his last email to TEI-L on the subject), the need to rope in @rend .

[cthomasdta]

I understand the idea that my example might be misleading, I might have not been good at defending it. But to me, here, I would actually argue that there is one "moment" but two dates, the same way you see two different words/two different lemma. Hence proposing:

<date calendar="#A" when="0000-00-00">Tuesday 7<date calendar="#B">/19</date> May</date>

to clearly differentiate both.

You would still have to add another @when which would, redundantly, contain exactly the same "0000-00-00" date as the other @when.

I agree with your tagging, but like I said in my posts, for time-economic reasons I would prefer

<date calendar="#A-B" when="0000-00-00">Tuesday 7/19 May</date>

or 2.
<date calendar="#A #B" when="0000-00-00">Tuesday 7/19 May</date>

Option 2. is not allowed, but (in my opinion) should be; that's what (to me) this proposal is about, but we all are on the same page now I guess.

[martindholmes]

Thank you Thibault for this interesting parallel. I think it's particularly interesting because it throws up the level of complexity that nested dates might bring. "Dienstag, 1./12. May" has a 1 which is Julian and a 12 which is Gregorian, followed by a May which is both. So if you were really concerned to tag this properly, you would have to do something like (using linebreaks for clarity, omitting @Whens and @when-customs): <date>Dienstag, <date calendar="#julian" next="#dateMonth">1.</date> / <date calendar="#gregorian" next="#dateMonth">12.</date> <date calendar="#julian_gregorian" xml:id="dateMonth">May</date> </date> That would enable you to truly reconstruct the full components of the date in each calendar. It's a bit ridiculous and very time-consuming. So unless you are truly doing calculations with this text, it's probably overkill. On the other hand, this: <date calendar="#julian #gregorian">Dienstag, 1./12. May</date> tells you everything you need to know, and has the advantage of only two <calendar> elements in the header. It also enables users to track the usage of each calendar through the document collection without too much effort -- something that's actually very interesting for those weirdo nerds like me who have become intrigued by how wonderfully complicated it all used to be. Janelle Jenstad and I did a presentation in Nebraska in 2013 called "Encoding historical dates correctly: is it practical, and is it worth it?" <http://dh2013.unl.edu/abstracts/ab-179.html> That could be the title of a whole section of the Guidelines. :-) Cheers, Martin

…

On 2020-08-28 3:05 a.m., Thibault Clérice wrote: I am not much in the community but I actually agree with @lb42 <https://github.com/lb42> : I feel like this change will create some readability issue (The date being at the same time Gregorian and Julian). I am still confused about why a nested tag would be that awful. It would not require to identify two dates, just identify the variation inside the first date. To take another example in what I feel would be a similar issue, although not exactly the same: <p>I found <w lemmaRef="#his #my">his (my)</w> gift</p> Wouldn't it be weird ? And to me, this discussion on ***@***.***| pushes in this direction... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2028 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASNASOBBCYGARUZGTRBE4DSC56OVANCNFSM4QNEOBPA>.

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca

[sydb]

My instinct is that I am strongly against. @lb42 gave convincing arguments against on the list 2020-08-27T04:48Z, which I will not repeat here and now.

I will add, though, an approach to thinking about a problem like this that I find useful. If I were consulting for a project that had complex dates like this, I would ask the scholars working on the encoding system “what do you plan to do with the encoded information?”. To be fair, I do not for an instant subscribe to the theory that one should not encode any feature of a text for which you have no immediate processing plans. That said, processing plans do come into play in the cost/benefit analysis of whether an encoding is worth the effort or not.

In this particular case I suspect that a simple TEI encoding, such as the following, would suffice.

<date when="1732-02-22">Feb. 22, 1732 (Feb. 11, 1731/32, O.S.)</date>

“What? No @calendar? You’re not giving the reader information about what (two) calendering system(s) was (were) used in the source!”. Right. Why? Because I suspect (and I could be wrong — discussed in a moment) that all of the actual processing that is planned for encoded dates can be supported by that encoding. We can highlight the date, give the normalized version in a mouse-over, allow the user to sort chronologically, etc.

There are three likely responses to my hypothetical suggestion to use a simple encoding. First, the scholars might simply agree. Yay!

Second (and perhaps most likely) they may assert that it is important to include information about the dating system not so much for planned automated processing of dates, but because their expected users need some explanation, lest they get all confused about the information being presented. That is, the requirement is pedagogical, not processing. That IMHO is a really strong reason to do something, but not a strong reason to use @calendar or other even more complex methods of expressing exactly which calendar is in use for each snippet of source text. I would lean towards having a <note>[1] that explains the dating in one place for the humans. E.g.

<note type="editorial" subtype="pedagogical" anchored="no" resp="#sbauman.emt">
  <p>In these personal logs <persName
  ref="maf:Christopher_Pike">Pike</persName> switched back and forth
  between the standard Gregorian dating system (e.g., a meeting with
  <persName ref="maf:Michael_Burnham">Burnham</persName> and <persName
  ref="maf:Ash_Tyler_(Klingon)">Tyler</persName> is given as <q>7th of October,
  ’57</q>) and UFP stardates (e.g., the entry the day before he was graduated from <orgName ref="maf:Starfleet_Academy">Starfleet Acadamy</orgName> day is
  dated <q>stardate 3210.04</q>).</p>
</note>

Third, the scholars may disagree because they actually have differential processing in mind. E.g., they may want to be able to display NS dates and OS dates in different colors, or generate a list of all the (normalized) dates for which the source document used one or the other particular dating system. In this case use of @calendar or two <date> elements might be necessary. But I do not see any significant advantage of @calendar="#C.Julian #C.Gregorian" over @calendar="#C.JulGre"; either of those allow me to list “those dates that include both systems”, and neither allows me to differentiate which snippet of text represents the date in which system.

So unless some further argument is raised in favor, I am still against.

---

[1] Either in the <notesStmt> or attached to each <date>; although I might be convinced this would be better placed in teiHeader/profileDesc/calendarDesc/calendar or in teiHeader/encodingDesc/tagsDecl/namespace[@name eq 'http://www.tei-c.org/ns/1.0']/tagUsage[@gi eq 'date'].

[martindholmes]

Hi Syd, There are many circumstances in which dating systems used by writers are wrong, mad, meaningless or impossible to convert to Gregorian. These dates in some ways are the most interesting. For instance, putative proleptic Julian dates in the BC range are usually only semi-historical or traditional; regnal dates may depend on disputed reign-initial dates; Julian dates (in England) may be expressed based on the year beginning on December 25, January 1, or March 25, and we may not know (in fact, the original writer may not know, having taken their date from another source) which is the case. Anno Mundi dates are fascinating but fundamentally fantastical. So I think the idea that you've solved the encoding problem just by supplying a Gregorian attribute is only helpful in some cases. Cheers, Martin

…

On 2020-08-28 8:08 a.m., Syd Bauman wrote: My instinct is that I am strongly against. @lb42 <https://github.com/lb42> gave convincing arguments against on the list 2020-08-27T04:48Z, which I will not repeat here and now. I will add, though, an approach to thinking about a problem like this that I find useful. If I were consulting for a project that had complex dates like this, I would ask the scholars working on the encoding system “what do you plan to *do* with the encoded information?”. To be fair, I do not for an instant subscribe to the theory that one should not encode any feature of a text for which you have no immediate processing plans. That said, processing plans do come into play in the cost/benefit analysis of whether an encoding is worth the effort or not. In this particular case I suspect that a simple TEI encoding, such as the following, would suffice. <date when="1732-02-22">Feb. 22, 1732 (Feb. 11, 1731/32, O.S.)</date> “What? No ***@***.***|? You’re not giving the reader information about what (two) calendering system(s) was (were) used in the source!”. Right. Why? Because I suspect (and I could be wrong — discussed in a moment) that all of the actual /processing/ that is planned for encoded dates can be supported by that encoding. We can highlight the date, give the normalized version in a mouse-over, allow the user to sort chronologically, etc. There are three likely responses to my hypothetical suggestion to use a simple encoding. First, the scholars might simply agree. Yay! Second (and perhaps most likely) they may assert that it is important to include information about the dating system not so much for planned automated processing of dates, but because their expected users need some explanation, lest they get all confused about the information being presented. That is, the requirement is pedagogical, not processing. That IMHO is a really strong reason to do /something/, but not a strong reason to use ***@***.***| or other even more complex methods of expressing exactly which calendar is in use for each snippet of source text. I would lean towards having a |<note>|[1] that explains the dating in one place for the humans. E.g. <note type="editorial" subtype="pedagogical" anchored="no" resp="#sbauman.emt"> <p>In these personal logs <persName ref="maf:Christopher_Pike">Pike</persName> switched back and forth between the standard Gregorian dating system (e.g., a meeting with <persName ref="maf:Michael_Burnham">Burnham</persName> and <persName ref="maf:Ash_Tyler_(Klingon)">Tyler</persName> is given as <q>7th of October, ’57</q>) and UFP stardates (e.g., the entry the day before he was graduated from <orgName ref="maf:Starfleet_Academy">Starfleet Acadamy</orgName> day is dated <q>stardate 3210.04</q>).</p> </note> Third, the scholars may disagree because they actually have differential processing in mind. E.g., they may want to be able to display NS dates and OS dates in different colors, or generate a list of all the (normalized) dates for which the source document used one or the other particular dating system. In this case use of ***@***.***| or two |<date>| elements might be necessary. But I do not see any significant advantage of ***@***.***="#C.Julian #C.Gregorian"| over ***@***.***="#C.JulGre"|; either of those allow me to list “those dates that include both systems”, and neither allows me to differentiate which snippet of text represents the date in which system. So unless some further argument is raised in favor, I am still against. ------------------------------------------------------------------------ [1] Either in the |<notesStmt>| or attached to each |<date>|; although I might be convinced this would be better placed in |teiHeader/profileDesc/calendarDesc/calendar| or in ***@***.*** eq ***@***.*** eq 'date']|. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2028 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASNASK4NYWDRU3IQHT5URTSC7B77ANCNFSM4QNEOBPA>.

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca

[sydb]

I have spoken to @martindholmes offline about this, and he has almost convinced me it is a good idea. So instead of being strongly against, I am now waffling.

I find the arguments he gave above relatively unconvincing. But he further pointed out that some documents (and he actually gave an example) may have dates in dozens of regnal dating systems in various combinations. Thus the suggested "#juliGreg" combined sort of value could require dozens to hundreds of combinatorial <calendar> entries.

That, IMHO, is a really strong argument in favor of multiple values on @calendar. In the end it may not win the day, but I think multiple values now deserves serious consideration.

[MegJBrown]

Example of use case: in 1588, Spain and England used different calendar systems. When creating propaganda around the Spanish Armada, William Cecil (pretending to be an embedded Catholic spy), used the Spanish calendar in addressing his letter to the French Ambassador. The dating of this letter is important in the timing of Armada news, while indicating the system is important to its political claims. The publication of this letter included multiple dates using multiple systems.

[martinascholger]

Council at VF2F likes the idea of multiple values on @calendar.

[MegJBrown]

Closing issue because Elisa did everything necessary