[tei-council] more on certainty

[Julia Flanders]

Here are some more specific assessments of the certainty= and exact= 
attributes on <date> and <dateStruct>, in the context of the cert= 
attribute. It didn't take 3 hours, so I'm still good to go on the 
verse chapter :-)

1. The state of play
In P4 we have the following provisions:
<date certainty=""> with suggested values "approx | before | after"; 
intended to capture "degree of precision"
<dateStruct exact=""> with suggested values "approx | before | 
after"; intended to capture "degree of precision"
For P5 so far Lou has changed the certainty= attribute on <date> to precision=.

Here are the things I think one can say in general about dates:
precision: how many decimal places
accuracy: how "true" or "correct"
certainty: our state of mind about truth or correctness
and also more specific date-like things, such as Gabriel Bodard's 
suggested "notBefore", "notAfter", which seem to me to be potentially 
useful specifications under the general heading of precision. (That 
is, they are a way of adding, slightly, to the precision of a date.)

2. Is precision useful on dates? yes, I think it is.
If so, how to encode it?
--both certainty= on <date> and exact= on <dateStruct> could be 
changed to precision= (already begun)
--but if the values for these attributes are intended to indicate 
"degree of precision", the suggested values from P4 are not good for 
this. It also seems to me that one can determine how precise a date 
is by looking at the value= attribute, which clearly shows whether a 
date is stated to the century, year, month, day, etc. So I would 
propose that the precision= attribute may be redundant; if someone 
wants to indicate how precise a date is, they should do so by using 
the value= attribute with a properly ISO formatted date.
--the impulse behind the P4 suggested values is reflected more 
successfully in Gabriel Bodard's suggestion that we add the 
attributes notBefore= and notAfter=. His additional proposal that the 
exact= attribute be used to indicate whether either or both of these 
is exact seems unnecessary: this kind of "exactness" seems to me to 
be more a statement about our level of knowledge than about the date 
itself; see below on certainty.

2. Is accuracy useful on dates? I think this is more difficult to say.
--dates that are transcribed may be transcribed accurately or 
inaccurately, but if the latter surely the encoder would not know (or 
else they'd fix it)
--dates that are supplied, i.e. those that originate with the 
encoder/project, may (in theory) be known to be accurate or 
inaccurate, but the latter case is a little bizarre to imagine.
--need to distinguish between inaccuracies (a person--e.g. an 
author--has a wrong idea) and errors (the text has a wrong value), 
but it's hard to know which is which. For instance, if you see the 
sentence

	The American Civil War ended in 1850

is it useful to say that the date is inaccurate? or would you be more 
likely to use <sic>?

3. Is certainty useful on dates? I think probably so, but there are 
several things about which one might be certain:
--in data which is being generated rather than transcribed, one may 
not be certain about whether a date is correct or not, and one might 
wish to indicate this fact. For instance, in transcribing interview 
data, one might have reason to doubt the correctness of all the dates 
of interviews conducted by Person X, who is known to have been 
suffering mental problems at the time and wasn't keeping good notes. 
The dates as recorded might be very precise, but also very uncertain.
--one might also wish to express uncertainty about the level of 
precision recorded.
--I don't see that it is useful to express certainty (i.e. a state of 
mind) concerning the exactness (i.e. the precision) of a date. One 
expresses the precision using the mechanism given above; one can say 
a date is notBefore a certain date (which itself can be expressed 
with whatever level of precision is appropriate). But expressing, 
additionally, ideas about whether the precision of that notBefore 
value is correct is just way too meta for me.

I'm leaving out here forms of uncertainty which affect the *reading* 
or *transcription* of the date, which would fall under <unclear>, etc.

If so, how to encode it?
--for the first case above, I'd say that a cert= attribute on <date> 
and <dateStruct> might be useful.
--for the second case, <certainty> seems to be the more appropriate element.

4. Summary
--consider whether precision= is really necessary: does it add to the 
information available in value=, or does it make that information 
available in a more tractable form?
--add notBefore= and notAfter= to <date> and <dateStruct>
--consider adding cert= to <date> and <dateStruct>
--don't try to capture level of accuracy in dates?

I hope this is useful.

best wishes, Julia