FR: Allow @period to have Datatype of "1–∞ occurrences of teidata.pointer separated by whitespace"

[wlpotter]

Currently, the TEI guidelines constrain the @period attribute to only a single value of type teidata.pointer. This proposal requests that the @period attribute be changed to allow "1–∞ occurrences of teidata.pointer separated by whitespace". There are many cases where a datable event occurs across the boundaries of multiple named-periods. The @period attribute, as it stands, cannot accurately nor precisely capture such cases.

As an example, take the following case from a project in the field of Classics. We would like to capture both the composition date of a given work and the named chronological period(s) that correspond to that composition date. We are using the chronology from The New Encyclopedia of Archaeological Excavations in the Holy Land, which we reference in a /TEI/teiHeader/encodingDesc/classDecl/taxonomy. This periodization has several chronologically overlapping periods.

For example, if we were to specify the composition date of Joesphus' Antiquities of the Jews using a tei:origDate, we would like to encode it as <origDate period="#nabateanKingdom #earlyRoman" notBefore="0093" notAfter="0094">93 - 94 CE</origDate>. (This example has been taken from the record here)The multiple attribute values on @period, however, will not validate with the current TEI schema.

[martindholmes]

+1 from me.

[sydb]

Seems like a reasonable request. But seems to me the Guidelines should not just say “you can use more than one”, but also have to say what more than one means. Only three possibilities jump to mind, but there may be others:

1. The event being discussed (in this case, the date of origin of a manuscript) occurred during one of the listed periods, we’re not saying which (quite likely because we don’t know for sure).
2. The event being discussed occurred during the overlap of all listed periods.
3. The event being discussed started sometime in the earliest period listed and ended during the latest period listed. (Then why are there more than 2?)

[jamescummings]

The period attribute "supplies a pointer to some location defining a named period of time within which the datable item is understood to have occurred."

I don't think more than that is necessarily needed (without trodding on some well-known dating wasp nests) in defining multiple pointers, @sydb. Just that it should be interpreted as pointing to multiple periods of time in which the datable item is understood to have occurred. You do not want to start legislating whether it starts in the earliest and ended in the latest. (Now imagine you are encoding date entries given in a non-linear time travel novel?)

I think your 1) is wrong in its assumption that it occured in only one of them. There are plenty of named periods of times which overlap or entirely cover each other. For example "The Middle Ages" and "The Late Middle Ages". You may wish to point to a date being part of both of these periods. Or other fields where there are competing theories of dating periods used so it could be all of them. Periods are such fuzzy concepts that I'd think of this more like categories rather than something precise.

Multiple pointers just mean all those apply in some vague undefined way that a project can specify in its metadata (maybe calendarDesc or similar).

[MegJBrown]

I agree with James: the need for multiple pointers doesn't require us to predetermine the relationship of all pointers to each other, or what is being described beyond "occurred within" which (to paraphrase) is in the current definition. The periods in question might be overlapping, from different disciplines ("Hand Press" and "Early Modern" overlap, but not entirely), or serve different purposes for the project. I don't think we need to be overly deterministic about how they relate to each other.

[martinascholger]

VF2F agrees to change teidata.pointer to 1–∞ occurrences.

[sydb]

Looks to me as if the examples given by both @jamescummings and @MegJBrown to support the idea that the Guidelines should not assign semantics to multiple values are using the semantics of #2. Is there an argument for #1 or #3?

BTW, #1 can be thought of as Boolean OR, and #2 as Boolean AND; #3 is a range, and (as mentioned earlier) would make most sense if @calendar were limited to 2 values. Thus I think Council has already kinda discounted #3.