Mark the origDate with @period

[davidamichelson]

https://github.com/srophe/caesarea/issues/6

[wlpotter]

@davidamichelson I've added period attributes. However, there are some overlaps in the taxonomy. An example would be from Josephus: https://github.com/srophe/caesarea-data/blob/master/data/testimonia/tei/4.xml#L228

As you can see from the example, I've added the different periods as space-separated pointers. We should decide if we want to allow multiple periods or not - likely a conversation with the editors. If we do go that direction, this is not something a script will be able to sort out anymore.

I'm leaving this open until we've discussed if having multiple period values is alright.

[wlpotter]

Multiple, space-separated period values is fine. Closing this issue.

[wlpotter]

@davidamichelson I'm reopening this because I noticed that the @period attribute with multiple, space-separated values is not validating. The attribute requires a teidata.pointer value, meaning it must refer to a single URI (can be relative or absolute, so something like "#earlyRoman" is valid but "#earlyRoman #nabataen" is not. See the TEI guidlines definition here: https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-teidata.pointer.html

Is this cause for us to change our practices? I understand why the teidata.pointer data type is so restrictive, but I don't agree with the application of it to the @period attribute as there are many cases when a date or date range would fall within multiple periods - as in our case, for example. We will need to discuss this.

[davidamichelson]

Yes, let's bring Dan in on this. Maybe a change request to TEI

On Fri, Mar 20, 2020 at 10:13 AM William L Potter notifications@github.com wrote:

@davidamichelson https://github.com/davidamichelson I'm reopening this because I noticed that the @period attribute with multiple, space-separated values is not validating. The attribute requires a teidata.pointer value, meaning it must refer to a single URI (can be relative or absolute, so something like "#earlyRoman" is valid but "#earlyRoman #nabataen" is not.

Is this cause for us to change our practices? I understand why the teidata.pointer data type is so restrictive, but I don't agree with the application of it to the @period attribute as there are many cases when a date or date range would fall within multiple periods - as in our case, for example. We will need to discuss this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/srophe/caesarea-data/issues/3#issuecomment-601751119, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXQ37OKGFITYO4V6Q5FCZTRIOBZPANCNFSM4LMLGAQQ .

[wlpotter]

Notes for TEI list:

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

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 file here)The multiple attribute values on @period, however, will not validate with the current TEI schema.

[wlpotter]

Here is an example record: https://github.com/srophe/caesarea-data/blob/master/data/testimonia/tei/10.xml#L238

[wlpotter]

Link to feature request: https://github.com/TEIC/TEI/issues/2002

[davidamichelson]

Good feedback from TEI council above.

I would suggest we propose this definition (which draws on language in the definition of @ref in att.canonical)

"supplies one or more pointers to some location defining a named period of time within which the datable item is understood to have occurred. If more than one pointer is supplied the implication is that the datable item occurred, at least in part, within all of the time periods identified. Ambiguous identifications (such as uncertainty, gaps, or overlaps in the chronological data) can be clarified by the TEI:precision element."

Examples for the <precision> scenarios would be:

Basic example without the need for <precision>: Data: Josephus' Antiquities of the Jews was written in 93 - 94 CE which is part of two different periodizations (the period of the Nabatean Kingdom, 168 BCE-106 CE and the Early Roman period, 37 BCE-132 CE)

Encoding:

<origDate period="#nabateanKingdom #earlyRoman" notBefore="0093" notAfter="0094">93 - 94 CE</origDate>

Uncertain overlapping example with <precision>: Data: Josephus' Lost Undated Sequel was written at an unidentified date between 100 - 110 CE which is potentially part of one or two different periodizations (the period of the Nabatean Kingdom, 168 BCE-106 CE and the Early Roman period, 37 BCE-132 CE). In most cases, it might not be necessary to annotate this ambiguity since the overlap is clear in the @notBefore and @notAfter values, but it could be expressed as follows if desired:

<origDate period="#nabateanKingdom #earlyRoman" notBefore="0100" notAfter="0110">93 - 94 CE
<precision match="@period" precision="low"><desc>This lost work may have been written either during the last years of the Nabatean Kingdom Period or in the portion of the Early Roman Period after the end of the Nabatean Kingdom Period.
</desc>
</precision>
</origDate>

Uncertain non-overlapping example with <precision>: Data: Josephus' Postmortem Biography was written at an unidentified date between 130-140 CE which is exclusively part of one of two different periodizations (the Early Roman period, 37 BCE-132 CE or the Late Roman Period, 132 CE-324 CE). In most cases, it might not be necessary to annotate this ambiguity since the numeric correspondence is clear in the @notBefore and @notAfter values, but it could be expressed as follows if desired:

<origDate period="#earlyRoman #lateRoman" notBefore="0130" notAfter="0140">130-140 CE
<precision match="@period" precision="low"><desc>This lost work was written either in the Early Roman Period or the Late Roman Period.
</desc>
</precision>
</origDate>

To address Syd's scenarios. Most of these scenarios become less ambiguous if date values supplied in the data and so might not need any clarification. But if they did they could use <precision>.

Responding by number:

1. This is the non-overlapping example above.
2. This is the default definition for using more than one pointer in @period (if what is meant is that it occurs during "at least one point" of the overlap of the periods, i.e. not necessarily implying that the event's duration was the same as the entire overlapping range).
3. This would be covered by the default definition.

[davidamichelson]

@wlpotter Did this ever get acted on by the council?

[davidamichelson]

• [ ] We should note this as an innovation in the TEI in the documentation.

[wlpotter]

@davidamichelson TEI council did approve this change, see https://github.com/TEIC/TEI/issues/2002#issuecomment-716172012

If TEI documentation updates, do we need to include in our documentation?

[davidamichelson]

Great, we want to make a note in our documentation that this was a change we requested.

[wlpotter]

Added to the documentation