[tei-council] certainty draft revised again

[Daniel Paul O'Donnell]

Lou,

This is really well done! It certainly seems to answer all my quibbles 
with the previous draft and it is as clear as the complexity of the 
material allows.

Some observations:

1) There is a bit of repetition (the middle sentence in each bit):

> For similar reasons, the certainty 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-certainty.html> 
> element may specify both a target value (expressed as an URI) and a 
> match value (expressed as an xpath). The former defines the context 
> within which the latter is to be found. If no target is specified, the 
> match pattern is evaluated in the context of the document root. If the 
> pattern does not match, the certainty 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-certainty.html> 
> assertion is considered to be null. 
and

> The match attribute used in these and other examples is a powerful 
> mechanism which can be used to indicate precision for a large number 
> of assertions throughout an encoded document in an economical way. If 
> target is defined in addition, then it defines the context within 
> which the match pattern is evaluated. If no value is supplied for the 
> target attribute, the context assumed is the root of the document. 
Perhaps move the unique content of the second and incorporating it in 
the first?

2) The introductory bit:

> The following types of uncertainty are /not/ indicated with the 
> certainty 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-certainty.html> 
> element:
>
>     * a number or date is imprecise
>     * the text is ambiguous, so a given passage has several possible
>       interpretations
>     * a transcriber, editor, or author wishes to indicate a level of
>       confidence in a factual assertion made in the text
>     * an author is not sure if the sentence chosen to start a
>       paragraph is really the one to be retained in the final version.
>
> Precision of numbers and dates is discussed in the following section, 
> 21.2 Indications of Precision 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/CE.html#CEPREC>, 
> and (for simple cases) in 3.5 Names, Numbers, Dates, Abbreviations, 
> and Addresses 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/CO.html#CONA>. 
> Well-defined ambiguity is handled with alternations in 
> feature-structure values in chapter 18 Feature Structures 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/FS.html>. 
> Uncertainty about the truth of assertions in the text and other sorts 
> of authorial and editorial uncertainty about whether the content is 
> satisfactory are not handled by the certainty 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-certainty.html> 
> element, though they may be expressed using the note 
> <http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/ref-note.html> 
> element. 
You might want to add something about transcription elements such as 
unclear to that last block of prose to handle cases under point two.  
Also, you could arguably claim that our example (whether Essex is a 
place or a person name) _is_ an example where certainty is being used 
because "the text is ambiguous, so a given passage has several possible 
interpretations." And in our discussion of @locus, we suggest that one 
possible use is "whether the content of the element or attribute is 
correct"--again something that could be understood as meaning "the text 
is ambiguous, so a given passage has several possible interpretations."

I imagine the distinction hinges on what we mean by "text." I think when 
you say "the text is ambiguous, so a given passage has several possible 
interpretations," you mean the actual reading of the letters? I.e. the 
type of thing that <unclear> should handle?

Also, in the case of the first bullet point in this list of what 
certainty does not refer to, "a number or date is imprecise," I think it 
might be wise to err on the side of being redundant in order to be 
really clear. The point is that we don't want certainty to be used to 
indicate precision (even if the answer is that the number or date is 
very precise). So for this first bullet, I'd say something like 
"[certainly should not be used to indicate] - the degree of precision 
intended in the representation of a number or date." I'm sure you'd be 
able to do better.

If I could ask a dumb question: why do we distinguish between certainty 
and precision? If the main difference is @stdDeviation, is there not a 
way of mushing them together?

3) Should we maybe consider a more strongly suggested list of values for 
@locus? I.e. location, elementName, attributeName, elementValue, 
attributeValue

-dan

Sebastian Rahtz wrote:
> Laurent Romary wrote:
>
>   
>> Can you give an entry point to it? I would like to read it throug once.
>>     
>
>
> have a look at
>
> http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/CE.html
>
> for the details. I just made a few corrections which had
> stopped it building earlier.
>
> http://tei.oucs.ox.ac.uk/P5/Guidelines-web/en/html/CE.html#CEPREC
> contains the new element.
>   

-- 
Daniel Paul O'Donnell
Associate Professor of English
University of Lethbridge

Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/)
Founding Director, Digital Medievalist Project (http://www.digitalmedievalist.org/)
Chair, Electronic Editions Advisory Board, Medieval Academy of America

Vox: +1 403 329-2377
Fax: +1 403 382-7191 (non-confidental)
Home Page: http://people.uleth.ca/~daniel.odonnell/