[tei-council] Certainty within milestoneLike

[Lou Burnard]

I don't think it's hard to find lots of cases where indication of 
uncertainty or imprecision *might be* needed. As soon as you accept that 
the markup is making an assertion, you may want to hedge that assertion. 
But that's why the <certainty> and <precision> elements are defined for 
use in a standoffish way -- so that they can be used generically as 
necessary. It's not an argument for introducing what I persist in seeing 
as an unnecessary complication into the way empty tags are defined however.

So far the only real case we've seen discussed (uncertainty about the 
location of a line break) can easily be solved by adding @cert and @resp 
to <lb/> -- a linebreak is *only* about location, so there's no need to 
specify the type of uncertainty concerned. Even if there were, a 
<certainty> element pointing to the <lb/> concerned doesn't seem to me 
to be much of an overhead.

I have commented to this effect on the ticket and look forward to being 
shouted down...


On 03/08/12 12:04, Gabriel BODARD wrote:
> On 31/07/2012 17:41, Kevin Hawkins wrote:
>> I can imagine uncertainty over where exactly a shift in hand
>> (<handShift/>) occurs or whether a pause (<pause/>) occurs at all.  So I
>> treat these like the milestone elements.
>
> I agree. Or which hand you're shifting to here, or various other
> information that might be recorded in attributes of these empty
> elements. I think this is right.
>
>> If you use <addSpan/> instead of <add> or <delSpan/> instead of <del/>
>> to get around an overlapping hierarchy problem, you could have a
>> situation where, when transcribing a manuscript, you can't tell exactly
>> which text was added or deleted.  So I would treat these like the
>> milestone elements.
>
> True. Or how a text is marked for deletion, or if you're recording an
> edition, various other information about the deletion or damage that is
> imperfectly recorded. Okay, I'm persuaded.
>
>> You sometimes use <ptr/> to mark sigla, and I suppose there might be old
>> printed books where it's unclear whether a smudge is a siglum or, say, a
>> quotation mark.  But I'm willing to let this go until someone raises it
>> as an issue.
>
> I'm so not convinced by this, to be honest, maybe because in my usage at
> least <ptr/> never represents something that's in the source text
> itself, but is used to indicate some kind of technical relationship
> within the markup. If anyone feels strongly I'm happy to revisit this,
> though.
>
>> The dictionaries chapter used to be named "print dictionaries" but was
>> renamed in order to suppport encoding of born-digital dictionaries.  I
>> strongly suspect these elements predate the renaming, and even if they
>> don't, we can't really say that no one uses these in encoding print
>> dictionaries.  I can imagine uncertainty about the placement of these
>> elements when transcribing an old dictionary, so I vote to treat like
>> the milestone elements.
>
> Fair enough. I don't know how the dictionary elements are used, but if
> oRef and pRef can take various interpretive meaning-bearing attributes,
> then there's surely call for asserting certainty/responsibility/etc on
> these attributes as well.
>
> According to James's comment on the ticket (and the minutes from AA),
> "unless there is great disagreement the FR should be approved and
> implemented". Does the lack of dissent over the last 4 days count as not
> great disagreement? Shall I go ahead and implement this?
>
> And are we talking about just adding model.certLike to the model of
> these elements, or model.glossLike (which will bring certLike with it)?
> I'm a bit confused to find that <precision> is a member of the latter
> but not the former, since I thought we explicitly created it as a
> <certainty>-like element...
>
> G
>
>