[tei-council] Examples for certainty|precision @match

[Martin Holmes]

I see the logic there.

If @target is used instead, with an xpath pointer, would the context 
node for that also be considered to be the parent node? If so, wouldn't 
that make the user of pointers in att.scoping/@target different from 
@target defined in e.g. att.pointing?

Cheers,
Martin

On 12-11-28 07:30 AM, James Cummings wrote:
>
> Whereas my intuition is telling me the exact opposite. ;-)
>
> If we have:
>
> <name type="place">Foo<certainty match="$" locus="value"
> degree="0.5"/></name>
>
> I think the certainty can't and *shouldn't* be able to refer to
> itself, that is what a nested certainty is for, therefore the
> default @target is an assumed parent::node(). So in this case $
> should be @type not ../@type.
>
> As Gabby pointed out the flaw in this reasoning of mine is where
> we want to be uncertain or imprecise about milestone elements
> which don't have certainty in them (lb for example).  That is why
> I'm with him in thinking they should have this content (and I
> think should have <desc> as well given recent discussion on TEI-L).
>
> -James
>
> On 28/11/12 13:49, Martin Holmes wrote:
>> This is a tough one. My instinct is that we should go with what seems to
>> be intuitive, and what's most intuitive to me is that if you specify
>> nothing, the default is the current context. In other words, the default
>> value of @match should be ".", and that if you want to point to a parent
>> element, you have to use "..". That means the examples should be
>> rewritten to:
>>
>> <certainty match="../@who" locus="value" degree="0.5"/>
>>
>> etc. And in realistic usage, the @match attribute would be required, to
>> prevent the <certainty> attribute from expressing uncertainty about itself.
>>
>> This would also make @match in line with @target; if @target contained a
>> TEI Pointer of some kind, that would be evaluated relative to the
>> current context <certainty>, wouldn't it?
>>
>> My head hurts when I think about this, though. <certainty> can contain
>> <certainty>, meaning that you could have a child <certainty> expressing
>> doubt about the value of the parent <certainty>'s @match attribute,
>> while the parent <certainty> could express doubt about the child
>> <certainty>'s @target. Gawd.
>>
>> Cheers,
>> Martin
>>
>> On 12-11-26 04:41 AM, Gabriel Bodard wrote:
>>> After fixing the problem with certLike having been inadvertently removed
>>> from the content model of <space>, I was about to add an example or two
>>> to the usage of <certainty> and/or <precision>, when I noticed an
>>> apparent inconsistency (or at least potential confusion) in the
>>> guidelines description of the @match attribute.
>>>
>>> At
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
>>> @match is defined:
>>> "supplies an arbitrary XPath expression identifying a set of nodes,
>>> selected within the context identified by the @target attribute if this
>>> is supplied, or within the context of the element bearing this attribute
>>> if it is not."
>>>
>>> I take this to mean that in the absence of @target, if I want to point
>>> to a <gap> element from a <certainty> inside it, I should write:
>>>
>>> <gap><certainty match=".."/></gap>
>>>
>>> (The example under match indeed gives match="parent::tei:gap/@reason",
>>> which I take to be consistent with my usage.)
>>>
>>> A note further down adds:
>>> "If neither attribute (sc. @target, @match) is present, the expression
>>> of certainty applies to the context of the certainty element itself,
>>> i.e. its parent element." (For starters, this should say "certainty,
>>> precision etc.".)
>>>
>>> But I take this to mean that an element <precision/> should be
>>> understood to have a default value of match=".." (rather than match="."
>>> which might be more intuitive). This is not inconsistent, but perhaps
>>> slightly confusing. (At the very least we should offer more examples here.)
>>>
>>> In the examples at
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
>>> (yuk!) however, we uniformly see values such as:
>>>
>>> <certainty match="@who" locus="value" degree="0.5"/>
>>> <certainty match="@resp" locus="value" degree="0.2"/>
>>> etc.
>>>
>>> Since the certainty element in these cases has neither who nor resp,
>>> this usage seems to imply that the starting point for the XPath in
>>> @match is the parent of the [certainty|precision] element that bears the
>>> @match attribute.
>>>
>>> On the one hand, it is probably simplest to say that the examples in CE
>>> are wrong and we should just fix them by prefixing all of these @ with
>>> ../ (which is how I've been using this attribute).
>>>
>>> On the other, however, if the starting point of the XPath were the
>>> parent element rather than the [certainty|precision] element itself,
>>> then it becomes less defensible to have some transcriptional elements
>>> that cannot take certainty or precision as children, as I argued at the
>>> last F2F. So I don't mind which way we go on this one. ;-)
>>>
>>> Any thoughts?
>>>
>>> G
>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)