[tei-council] report on certainty

[Julia Flanders]

I have to apologize for the lateness and sketchiness of this report.

I had originally thought that in reviewing <certainty> and cert= I 
would find a great deal to change. However, after reviewing the 
discussion on TEI-L concerning certainty mechanisms, it seems as 
though people are generally content with the existing mechanisms. The 
areas of debate seem chiefly to concern how precise to be in 
assigning uncertainty. The approach Lou has been presenting (default 
three-value approach built in, extensible by the user) seems 
sensible; I believe that for most purposes it will not be possible to 
say more than "high|medium|low" and encouraging people to use those 
values is useful.

One interesting distinction was raised by Tim Finney, concerning a 
possible distinction, within the concept of "certainty", between:
--identifying how close one thinks one's encoding/transcription/etc 
is to the actual
--identifying how repeatable or "popular" an encoding is: how likely 
it is to be agreed with (this is what Finney called "precision"  but 
I don't think this is a good term in this context)

This is ingenious, but I don't think it's essential. In practice, 
it's difficult to assess how close an encoding is to being correct, 
except by saying something like "I'm [not | sort of | very] sure...", 
and assessing how repeatable an encoding is would be equally 
difficult.

Concerning the existing <certainty> element:
--the current attributes are reasonable, provide a way to point to 
the range of things one needs to comment on; most people don't 
need/won't be bothered to use these, but for the enthusiast they seem 
adequate based on the feedback we've had
--desc= will need to be a child element (but this is already 
contemplated, right?)
--degree= should use same values as cert= (?) since whatever insight 
we have about appropriate levels of precision will apply equally to 
both.

It would be helpful to add a recommendation of where in the document 
the <certainty> elements should live, and perhaps also to restrict 
where they go. At the moment, they could go anywhere, and I'm not 
sure this is useful. Would it make sense to create a place in the 
header for this kind of metacommentary? This would make it easier to 
contemplate processing the information systematically.

Best wishes, Julia

>1) Review of the minutes and action items (10 min)
>
>    Minutes of the meeting are at
>	 http://www.tei-c.org/Council/tcm18.html.
>
>	 To speed up the review of action items, *please report to the
>	 council list* before the call as far as possible!
>
>	 We will discuss the reports during the call as necessary.