calendar= should not be in att.datable

[sydb]

The @calendar attribute is currently a member of att.datable, but should not be.

This is because @calendar is, by definition, about “the date represented by the content of this element”. But among the members of att.datable we find several elements whose content is not a date (e.g., <orgName> or <unitDef>), and lots of elements whose content need not include a date (e.g., <acquisition> or <climate>).

So it is clear to Council that @calendar should split out of att.datable. There are some issues still to be resolved, however:

• should @calendar be put into a class of its own? (My vote is “yes”)
• if so, what should that class be named? (“att.dated”, maybe?)
• which elements should retain @calendar and which should lose it?

[sydb]

Personally, I feel this (@calendar in att.datable) is a corrigible error, and thus need not be deprecated. I have learned, however, that this is a controversial opinion that others do not share. Thus I am planning to put this removal through a 1-year deprecation period unless I hear support for the idea that such an egregious error can just be corrected without deprecation.

I hope I do hear “deprecation not needed”, because deprecation is quite a pain in this case. We cannot just add @validUntil to the appropriate <attDef>, because then proper @calendar attributes would get flagged, too. So to deprecate we need to remove @calendar from att.datable, and then add it back to all the members of att.datable (either directly or through 2 new classes), and add @validUntil where appropriate. Then, at the end of deprecation, we have to undo half of that.

Furthermore, my plan is that we keep @calendar only on <date>, <origDate>, and <time> (my answer to the last bullet point in previous post).

[martindholmes]

@sydb What about the syntactic-sugar date elements like <birth>, <death> and <floruit>?

[sydb]

Those three (at least) are definitively not syntactic-sugar for <date>:

<birth>: contains information about a person's birth, such as its date and place.
<death>: contains information about a person's death, such as its date and place.
<floruit>: contains information about a person's period of activity.

Examples from the Guidelines:

<birth when="1960-12-10">
  In a small cottage near
  <name type="place">Aix-la-Chapelle</name>,
  early in the morning of
  <date>10 Dec 1960</date>
</birth>

<death when="1960-12-10">
  Passed away near
  <name type="place">Aix-la-Chapelle</name>,
  after suffering from cerebral palsy.
</death>

Although to be fair, there are no examples of <floruit> that have other than date (or date range) content. Furthermore, there are some examples of these three that do imply the date is the important thing. E.g.:

<birth when="-0044-03-20">
  20 March 43 BC
  <placeName>
     <settlement type="city">Sulmona</settlement>
     <country key="IT">Italie</country>
  </placeName>
 </birth>

That said, I do not currently have strong feelings that they should not bear @calendar; only a mild feeling that if you need it, maybe there should be a <date> child.

[hcayless]

For the record, I think that this is absolutely a corrigible error and should not be subject to deprecation.

[lb42]

Deprecation is entirely unnecessary. It makes no sense for @Calendar to be datable, unless you think decisions about which calendar is being used in a given situation might change over time,

[duncdrum]

I don’t think that the current behaviors sanity or corrigibility should be the determining factor when it comes to the question about deprecation.

If existing valid code will become invalid and require work, because of changes in this commit, those changes require a deprecation period.

If dated calendars are silly and no one uses it, then no one will mourn. But deprecation seems the way to go to me.

[sydb]

While it may not change your opinion, @duncdrum, I think you may be missing the point on two fronts.

First, the very definition of “corrigible error” (here in TEI-land) includes that no deprecation period is required.

But more importantly, although use of @calendar on, say, <orgName> may have been inadvertently permitted by the schema, it was not part of the abstract model. So correcting it in the schema is merely bringing the schema in line with the prose, as it were.

And, it is worth realizing, that the only difference to a wayward user who has used @calendar on <orgName> is as follows: With deprecation she has to change her data before she can upgrade to version 4.4.0 or 4.5.0 (or whatever). Without deprecation, she needs to change her data before she upgrades to 4.2.0.

I think that use of something like <orgName from="1532" to="1555" calendar="#whatever"> to assert that 1532–1555 is expressed in the whatever calendar instead of proleptic Gregorian (as @from and @to are defined as being in) is so egregiously problematic that the faster she changes her data the more likely she avoids significant confusion or problems.

That’s just my 2¢, though.

[martindholmes]

@sydb The example above doesn't mean what you suggest: @calendar refers to the text content of the element, not the value of dating attributes. Whether it would be wrong to say <orgName from="1532" to="1555" calendar="#whatever"> is wrong would depend on the text content of <orgName>; it has no connection with the @from and @to attributes. If I want to use a non-Gregorian calendar in dating attributes, I can do it like this:

<orgName from-custom="1532" to-custom="1555" datingMethod="#julian">

which seems perfectly fine to me, especially for calendars that don't easily convert to Gregorian.

[sydb]

Yes, @martindholmes, I know it doesn’t mean that. My point is if the mythical scholar in my example does think that, I would like to disavow her of that misunderstanding sooner rather than later.

[duncdrum]

While it may not change your opinion …

@sydb correct, it doesn’t

[martindholmes]

With @sydb. Here's a list of elements that have it:

element	Needs @calendar?
acquisition	no
affiliation	no
age	no
application	no
binding	no
birth	no
bloc	no
change	no
climate	no
conversion	no
country	no
creation	no
custEvent	no
date	yes
death	no
district	no
education	no
event	no
faith	no
floruit	no
geogFeat	no
geogName	no
idno	no
langKnowledge	no
langKnown	no
licence	no
location	no
name	no
nationality	no
objectName	no
occupation	no
offset	no
orgName	no
origDate	yes
origPlace	no
origin	no
persName	no
placeName	no
population	no
precision	no
provenance	no
region	no
relation	no
residence	no
resp	no
seal	no
settlement	no
sex	no
socecStatus	no
stamp	no
state	no
terrain	no
time	yes
title	no
trait	no
unitDecl	no
unitDef	no

To summarize, only <date>, <time> and <origDate> need it; and we also think that <docDate> deserves both @calendar and att.datable, and its own custom @when should go away.

[duncdrum]

He is now <age calendar='sui'>2 years</age> old makes a lot of sense to me, for age descriptions in context where baby's are 1 at birth (as opposed to 0 as is the norm in english).
there are probably similar arguments to be made for <state> and <trait> although i can't come up with any while
still reeling from the 1 🎂 🥳

[martindholmes]

@duncdrum You're pointing at a file called "sui" containing only a <calendar> element. That can't be right, surely?

But the broader point you're raising is whether durations should be datable, as opposed to dates/datetimes/date ranges/datetime ranges. I don't know for sure, but I don't think so. Are these special years defined differently from regular years, or are they just the same years we're all familiar with? Could a reader read "2 years" and wonder to themselves "I wonder what he means by years, here; are they regular years, or something weird and different that needs documenting?"

[duncdrum]

@martindholmes they are years, it’s just that a person that is 20 years old in Canada was born in 2000, while a Chinese person was born in 2001. So in translation or other documents that go back and forth, we have to wonder all the time, how old the speaker really is.

And no I missed the # the sui calendar being explained via clendarDesc in the header.

[martindholmes]

@duncdrum But the age element says nothing about when someone was born; that's irrelevant. For it to be relevant, there would have to be mention of a date on which that person was two years old, and it's that date that may need a calendar. But in that case, you should surely use custom dating attributes, wouldn't you? @calendar is only for cases in which a true datetime is in the original text of the document.

[sydb]

But (he asked curiously of @duncdrum) is that differnce really a calendar difference, or a cultural difference?

I can, however, imagine <age calendar="#DCU_Martian">65</age> in the personographic entry for J’onn J’onzz.

Nonetheless, I am against providing @calendar on <age> barring an actual use case.

[duncdrum]

When either transcribing interviews or government documents, there are often date and and age fields or statements. The above example is very much an actual use case, I as an editor need to supply this info or otherwise the two twenty year olds interviewed by me on the same date refer to different years in their accounts.

[sydb]

If I understand you correctly, @duncdrum (and I well may not), that is an argument for being able to normalize the value in <age>, but not an argument for doing so with @calendar in particular. The difference does not seem to be one of calendar, but one of counting. (More similar to the age-old argument of whether arrays should be indexed starting from 0 or 1 — ask a C programmer and an XSLT programmer and watch the sparks fly! — than to Gregorian vs Julian, no?)

Seems to me using @type (of which "sui" is one of the suggested values) makes more sense.

And keep in mind that if someone were, for some reason, to put a date into <age>, the calendar for that date can be indicated with the @calendar of a <date> child of <age>.

[martindholmes]

@sydb for this:

<age calendar="#DCU_Martian">65</age>

you would surely use a unitDef and a unit element to specify that these years are not earth-years. A quantity of time is not a date, I don't think; it's a measurement. A calendar is a way of specifying points on a timeline, and the timeline may be divided into units of various kinds, and you may or may not specify those dates using some of those units; but the fact that (for example) a calendar year may start on Jan 1, March 1 or March 25 doesn't change the length of a day or a year.

[duncdrum]

It’s getting quite late here, I did a quick search for my use of @calendar And have found instance of quite a few of the elements in Martin’s list. Now it’s possible that I have used this wrongly, but it’s also possible that you guys are missing the point.

I ll post some excerpts from one of my projects in the next few days so we can get this sorted.

but the fact that (for example) a calendar year may start on Jan 1, March 1 or March 25 doesn't change the length of a day or a year.

@sydb it can if eg your event is on February 27. But the interview is on the next January 1st. In calendar a (that of the interviewer) we have completed one annual cycle and are in plus 1 territory, in calendar b (the interviewees) we haven’t completed the annual cycle and are still in +-0.

This is a fairly common problem in court documents between the Chinese and the British empires, when trying to determine how much time has passed between events, or when a deadline is up for e.g. returning a colony island after 99 years. Of course the official lunar calendar doesn’t always start on March 1 but on a different day every year, making this even more fun.

[martindholmes]

@duncdrum I still think you're confusing measurement with dating, but let's take a clear example for discussion. A Martian calendar is presumably delimited in Martian days (24 h 37 m 22.663 s in earth-time). If you're tagging a text written by a Martian, and they use the word "day", meaning a Martian day, in a sentence:

On that day, he was arrested.

How should we tag that word "day"? We can't tag it as a <date>, because it isn't one -- although the phrase "that day" is arguably taggable as a date, in which case, we can use @calendar on <date>, and @datingMethod etc. to explain it in detail. But if, inside there, we want to explain that the duration of that day is X number of earth-seconds, we can do that in a number of different ways, including @dur-iso on the <date> element, or by tagging the word "day" as a <unit type="time"> (used in a Guidelines example), and using @unitRef to point to an explanation of it. You might mention or point to a calendar in the <unitDef>, but it's surely possible that there are multiple Martian calendrical systems; the length of a Martian day is not a property of one specific calendar.

Let's say there is a unit of time called a blurg, which is a property of one Martian calendar alone, and it consists of 9 Martian days:

During that blurg, he was arrested.

Again, "that blurg" is a date or a date-range, and can be tagged that way. But "blurg" is still a unit, not a date. @calendar "indicates the system or calendar to which the date represented by the content of this element belongs." "blurg" doesn't represent a date, so @calendar isn't appropriate, surely?

The same applies to <age>65</age>; it's not a date, it's a quantity, and if you need to explain it you can use <measure unitRef="#martianYear">. But I don't think you can use @calendar unless you change its definition.

[duncdrum]

Part 1: Why I think that there is a problem.

As promised, here it goes. Let's ignore for a moment the xml xs:date pecularieties concerning BCE dates.
And let's also forgo the detailed calendrical math stuff. The point is that documents contain dates we wish to deal with in tei.

So let's look at the OPs example:

<birth when="-0044-03-20">
  20 March 43 BC
  <placeName>
     <settlement type="city">Sulmona</settlement>
     <country key="IT">Italie</country>
  </placeName>
 </birth>

And use a similar Chinese example from the same period from one of my projects, slightly modified for comparison:
This guy in case you're curious

<death when="-0048-01-10">
  黃龍一年十日
  <placeName>
     <settlement type="city">長安</settlement>
     <country key="CN">西漢</country>
  </placeName>
 </death>

@calendar allows an editor to extract the date string from the document and turn it into something sensible.

<death when="-0048-01-10" when-costum="7R-1Y-10D" calendar="#chinReign" datingMethod="#chinTrad" period="#D29-E10">
  黃龍一年十日
  <placeName>
     <settlement type="city">長安</settlement>
     <country key="CN">西漢</country>
  </placeName>
 </death>

The point is that @datingMethod and @calendar are not the same. Also note the missing date element.

In the above encoding I use @datingMethod to describe the underlying lunar based calendar that goes in cycles (gengzi), which are shared across China at the time.
The thing you find in the text, is the reign date, which is specific to each emperor, and in times of multiple competing dynasties there are separate reigns.
The start of a reing does not have to fall on the 1st day of the first month of the year either.

I don't have strong feelings about which one should go into which attribute, my point is they both serve a purpose. And that allowing @calendar on things other then <date> does not strike me as arbitrary as the discussion so far makes it out to be.
But i have a strong sense that many of the not-date elements, in the above list, can contain date-like strings, which might require a @calendar attribute if the date is sufficiently non biblical.

Now i think we can do better e.g. demanding that when @calendar appears one of the @when-costum variants could make sense. Or we could mandate <date> elements (which would invalidate the Guidelines example)
, or .. i ll leave that to Part2. No point in going any further if y'all don't see the problem that i m seeing.

[martindholmes]

Just to clarify: your dates have been converted to proleptic Gregorian already, right? Hence the use of @when.

[duncdrum]

Just to clarify: your dates have been converted to proleptic Gregorian already, right? Hence the use of @when.

Yes @when normalized relative to xml version. @when-custom the reason we need @calendar in the first place.

[martindholmes]

@duncdrum If this is the date:
黃龍一年十日
Why not just wrap it in a date element?

[duncdrum]

@martindholmes because I don’t have to, it’s an adaptation of @sydb example from the guidelines.

birth does not demand date, so it taking @calendar makes sense, unless a whole bunch of rules get changed.

I switched birth for death because historical accuracy.

[martindholmes]

@duncdrum But when you use @calendar on <death>, you're implying that it applies also to the other content in there, aren't you? You're saying that it applies also to the city and the country. I think that's just sloppy markup, to be honest.

[sydb]

Yes @when normalized relative to xml version. @when-custom the reason we need @calendar in the first place.

No, @dating-method is how you indicate the <calendar> that applies to @when-custom.

[duncdrum]

think of a birth-certificate.

@calendar is about

the date represented by the content of this element

irrespective of transcription or meta-data. neither of which hinges on membership with att.datable

109-11-25 when processed by NER will correctly be tagged as <DATE> so will 黃龍一年十日 it's not like ppl don't open novels by saying on such and such a day ...

[duncdrum]

part 3 to sum up

there are problems with att.datable and there are problems with the triplet of @calendar @datingMethod and @period. Neither of which is resolved by removing @calendar from att.datable that's the red herring solution imv.

I do not see the class membership as an error in the first place. Certainly as something requiring deprecation.

What council wants to do about the problems, if anything, is up to council.

[martindholmes]

But a birth certificate is a document that would be transcribed in the text or sourceDoc element; it's not a piece of metadata appearing in the header or in the linked data container. So it wouldn't have <person> in it, and therefore it wouldn't have <birth> in it.

[duncdrum]

Looking at @sydb list of elements, these can and do occur outside of the header in the text section, the Guidelines even show pseudo-prose for the contents of<birth>. If it's ok to use <orgName> inside <body> and it is in att.datable then @calendar needs to be in att.datable. If <birth> appears in the header with prose contents, and it can have @when it also needs @calendar.

[martindholmes]

<birth> etc. can only occur as in person, personGrp and persona. Those are metadata elements. persName, orgName and so on are not metadata elements, and they may occur anywhere in transcribed text as well as in header elements. Any element needing @calendar would get it by means of another class after it's removed from att.datable (if that's what ends up happening). The only question is where it makes sense to have @calendar; the mechanics are straightforward. I think @calendar should be more clearly and specifically defined to say that it relates to transcribed source text, and that it doesn't belong on those pure-metadata elements. But I don't think I'll ever convince you, so I'll retire at this point. :-)

[duncdrum]

@martindholmes i can totally be convinced that this is a good idea, as part of more wide ranging changes about dates that increase consistency, adjust validation scenarios, and modify the guidelines prose and examples.

Since this discussion started with status green, no deprecation necessary, I went by what’s in this ticket. I’m so far against the removal, but it’s not my call. But I think I stated my case, up to council what to do with it.

As always thanks for the constructive discussion.

[sydb]

Herein I will use @when as a stand-in for the attributes in att.datable.w3c and att.datable.iso, and “date” to mean “date, time, duration” or other temporal expression usefully normalized.

I think one way to look at this is that @when says “this thing happened at or represents a specific date, and here is the normalization of that date”. They do not say “there might be a date buried somewhere in my content, here is the normalization of that date”. Whereas @calendar is not about the date on which something (like acquisition of a manuscript) happened, but rather about which <calendar> should be used to interpret the transcribed content that represents a date.

I think it is unusual, but quite reasonable, to want to do both. I.e., to say “this object was acquired on stardate 4570.8”. But it seems to me important enough to avoid the “@calendar is about @when” confusion that it does not bother me to insist that the stardate be transcribed inside a <date> inside the <acquisiton> just so it can have an @calendar. Besides, I do not like the idea that in

       <acquisition when="2327-07-28" calendar="#stardate">
         A gift from <persName>Maurice Picard</persName>
         to his daughter-in-law <persName>Marie Picard</persName>
         in 4570.8, in celebration of her son’s birth.
       </acquisition>

the phrases “A gift from” and “her son’s birth” are in a calendar, or subject to different interpretations based on a calendar. I would much prefer to see

       <acquisition when="2327-07-28">
         A gift from <persName>Maurice Picard</persName>
         to his daughter-in-law <persName>Marie Picard</persName>
         in <date calendar="#stardate">4570.8</date>, in celebration of
         her son’s birth.
       </acquisition>

Am I being crazy? (Has been known to happen.)

[martindholmes]

@sydb I agree 100%. I think a date element should be used to clarify that the @calendar applies only to a string of text that is explicitly a date. I'm completely unconvinced by the idea that calendars apply in some weird way to other things such as locations; and even if there's an argument that they do, they don't apply in the same way as they do to a date, so the explanation of that relationship belongs somewhere else (in the place element itself, I think).

[duncdrum]

Am I being crazy? (Has been known to happen.)

Nope, but omitting an answer why a) mandating the following doesn’t follow from restricting @calendar to appear on <date>

        <acquisition>
          A gift from <persName>Maurice Picard</persName>
          to his daughter-in-law <persName>Marie Picard</persName>
          in <date when="2327-07-28" calendar="#stardate">4570.8</date>, in celebration of
          her son’s birth.
        </acquisition>

And b) how to preserve the editors freedom to go easy on attributes, and have something like this available

<acquisition calendar=‘#stardate’>4570.8</acquisition> 

Stardates, reign dates, lunar dates etc. are normalized via the calendarDesc, they're just not closely following the proleptic Gregorian xs:date format that is baked into xml. I m still non the wiser about @period shouldn’t that also have the same restrictions as @calendar?

@when says “this thing happened at or represents a specific date, and here is the normalization of that date”. They do not say “there might be a date buried somewhere in my content, here is the normalization of that date”.

I'd say that's a reinterpretation of the data-model, the model as it is now does not say that. In fact you can read the birth examples sans date to say exactly the opposite. If you want the model to say that, we need to address more then just @calendar class membership in att.datable

[duncdrum]

btw @martindholmes it just occurred to me that we are using transcribed to mean different things, i think you restrict it to what appears inside <tei:body> where as i also call something transcribed if it appears in the head (metadata) but it sticks to the appearance on the original document.

So in this context, i would use

<acquisition calendar=‘#stardate’>4570.8</acquisition> 

to transcribe a document which has a Seal or stamp on which the string 4570.8 indicates a the stardate. I honestly don't care where in the TEI document the transcription ends up, but I always aim to use element contents for transcription, and reserve attribute values for editorial additions.

I.E. I ve probably been doing it wrong for all those years 🤯

[martindholmes]

That's exactly right.

[duncdrum]

Hah at least we got that sorted! I ll drop the term, but will gladly continue the practice, which doesn’t strike me as that wild an approach 👺

PS: to be clear there would always also be a proper transcription in the body.

[martindholmes]

This is basically why we believe that @calendar is fundamentally different from the other dating attributes and belongs in its own class; it's saying something about original transcribed text. The only way I'd use it in a metadata element would be if that element contained a quotation from the source, and the quotation contained a date.

[duncdrum]

Yes I see now where you want to go. Can you also see why I think that nowhere in its spec, nor in other date and calendar prose does it say that?

If editors want to use element contents in the header to mirror the data format in the document, i say let them. Also what about @period same thing or different, if different how so?

[martindholmes]

You're right that we don't specify that anywhere in particular, which is why I've been careful to say that it's my understanding of the situation rather than being necessarily the truth. And I really don't know how @period fits into this, frankly; it seems distinct from @calendar, and is perfectly suitable for use in both text and metadata.

[JanelleJenstad]

FWIW, MoEML has good documentation on how we use @calendar at https://mapoflondon.uvic.ca/encoding_dates.htm#encoding_dates_julian.

[raffazizzi]

After further discussion, Council is leaning towards removing @calendar from att.datable via deprecation.

A few reasons for this based on the conversation above:

• Global sloppiness: I would argue that sloppiness is already possible in metadata elements like <birth> in both Gregorian and other cultural calendars. If there is a date string in <birth> that is not encoded with <date>, it is not guaranteed to be a date in any way: it's entirely up to the human reader interpretation or further processing like a regex.
• @when: @when on conforms to an international standard, regardless of the content of <birth>. As Martin suggested, it can be further supplemented with @datingMethod and @when-custom to record additional metadata closer to the original system.
• Metadata v. Transcription. <birth> and the like are metadata fields. If calendar dependent dates need to be transcribed in the text, other elements that will remain members of att.datable can be used.

[ebeshero]

Council F2F decides to keep @calendar only on <date>, <time>, <origDate>, and <docDate>.
To help clarify its usage, we will create a new attribute class for it called att.calendarSystem, and we will deprecate its use on any other elements, for 18 months. Action on @raffazizzi to set up the deprecation @validUntil mechanism.

[HelenaSabel]

@raffazizzi during the update of att.datable, could you change the definition of @period? Could you replace: (typically <gi>category</gi>s or <gi>calendar</gi>s)
with:
(typically <gi>category</gi>s, <gi>date</gi>s or <gi>event</gi>s)