[tei-council] certainty revised

[Martin Holmes]

Lou Burnard wrote:
> Martin Holmes wrote:
>> Here's my couple of cents on the first part -- I haven't had time to get 
>> through it all yet:
>>   
> Hope you havent been too dispirited to continue...

Sorry -- got distracted. Here's a bit more:

--------------------

The current documentation for <certainty> 
(<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-certainty.html>) 
includes an example based on:

Ernest went to <anchor xml:id="A1"/> old
<persName xml:id="SYB">Saybrook</persName>.

and it says "For discussion of this example, see section 21.1.2 
Structured Indications of Uncertainty", but the example discussed in 
21.1.2 is now the much better (IMHO) example of Elizabeth and Essex.

--------------------

The example of the abbreviation expansion of SGML looks like this:

You will want to use
<choice>
  <expan xml:id="CE-e1">Standard
    Generalized Markup Language</expan>
  <expan xml:id="CE-e40">Some Grandiose Methodology for Losers</expan>
  <abbr>SGML</abbr>
</choice> ...

<!-- ... -->
<certainty target="#CE-e1" locus="value" degree="0.9"/>
<certainty target="#CE-e40" locus="value" degree="0.5"/>

I suspect that the second @degree value should be "0.1", shouldn't it? 
Don't the two have to add up to 1?

---------------------

Finally, I find myself a little puzzled by the application of 
<precision> to @notAfter, @notBefore, etc. My habit in using these 
attributes has been to decide once and for all, based on known 
information and logical deduction, what the _actual_ earliest and latest 
possible dates would be. It seems a little odd to me to say that 
something is "not after 1857", but there's a 50% chance that it might 
be. If you're not sure it's @notAfter="1857", then you need to move your 
@notAfter value forward until you can be sure, don't you? In my 
experience, there always _is_ a genuine value for @notBefore or 
@notAfter -- in the case of an action by a person, for instance, the 
date before which they were definitely not born, the date after which 
they were definitely dead, or the point at which they would have been so 
old as to break all known longevity records. After all, @notAfter is 
defined as specifying "the latest possible date".

One example from the text:

<residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to
some time in April of 1857.
<precision match="@notAfter" degree="0.5"/>
</residence>

Now, if "some time in April" is true, then @degree should surely be 
"1.0". If "some time in April" is doubtful, then surely so is "the 1st 
of March". But if there is doubt, that doubt presumably originates in 
external evidence, which ought at least to be adduced, and which itself 
would presumably give a more realistic value for @notAfter.

Hope this helps.
Martin



>> ---------------------
>>
>> QUOTE:
>>
>> [one]
>> the note element defined in section 3.8 Notes, Annotation, and Indexing 
>> may be used with a value of certainty for its type  attribute.
>>
>> [two (example)]
>> <persName>Elizabeth</persName> went to <placeName>Essex</placeName>. She 
>> had always liked <placeName>Essex</placeName>.
>> <note type="uncertainty" resp="#MSM">It is not
>> clear here whether <mentioned>Essex</mentioned>
>> refers to the place or to the nobleman. -MSM</note>
>>
>> COMMENT:
>>
>> The text says type="certainty", the example shows type="uncertainty".
>>   
> 
> Well spotted. Fixed.
> 
>> ---------------------
>>
>> QUOTE:
>>
>> @match  	supplies an arbitrary XPath expression identifying a set of 
>> nodes, selected within the context identified by the target attribute if 
>> this is supplied, or by the parent element if it is not.
>>
>> COMMENT:
>>
>> This was at the heart of the previous discussion, and for me it's still 
>> not absolutely clear at this point in the text. The parent element of 
>> what? Later we learn that it's the parent of the <certainty>, 
>> <precision> or <respons> element bearing the @match attribute, but I 
>> think it would help to specify it here.
>>
>> ---------------------
>>
>>   
> 
> Um yes. "by the context of the element bearing the attribute, i.e. its 
> parent" .
> I think.
> 
> 
> 
>> QUOTE:
>>
>> [one]
>> The certainty element is designed to encode the following sorts:
>> [...]
>>      * the content of an element is uncertain, perhaps because it is 
>> hard to read or hard to hear, or for some other reason.
>>
>> [two (just below)]
>> The following types of uncertainty are not indicated with the certainty 
>> element:
>> [...]
>>      * the document being transcribed may be read in different ways (for 
>> this use the transcriptional elements such as unclear, discussed in 
>> chapter 11 Representation of Primary Sources)
>>
>> COMMENT:
>>
>> These seem in direct contradiction: the first is saying "use <certainty> 
>> where the text is uncertain because it's hard to read", and the second 
>> is saying "don't use <certainty where the text may be read in different 
>> ways because it's unclear". If this isn't a contradiction, then I think 
>> it needs more detailed explanation.
>>
>> ---------------------
>>
>>   
> 
> There is a problem here, certainly :-) . I think the first means "use 
> certainty when you don't know what the unknowns are" and the second 
> means "you know what the unknowns are but you dont know which you want", 
> and will try to rephrase accordingly. But it's a rather nebulous 
> distinction... and maybe in fact we should do better to be honest and 
> say we have two rather different mechanisms and you can choose whichever 
> you like.
> 
> 
> 
>> QUOTE:
>>
>> locus  	indicates more exactly the aspect concerning which uncertainty 
>> is being expressed: for example, whether the markup is correctly 
>> located, whether the right element or attribute name has been used, 
>> whether the content of the element or attribute is correct, etc.
>>
>> COMMENT:
>>
>> Since @locus is constrained to one of five fixed values (according to 
>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-certainty.html>, 
>> I think it would be best to specify that here. As it reads now, you 
>> might get the impression that anything goes.
>>
>>
>>   
> 
> Good point. Will adapt accordingly.
> 
>> Hope this helps,
>>   
> 
> Very much so.
> 
> tx
> 
> .
> 

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
Half-Baked Software, Inc.
(mholmes at halfbakedsoftware.com)
martin at mholmes.com