[tei-council] Precision

[O'Donnell, Dan]

I've got two questions/comments, prefaced by thanks for all the brow furrowing.

1) what are the implications for existing P5 docs?
2) I'm really intrigued by the @target @path but still wonder about it. It seems redundant to me and a dangerous thing to be getting people to split up xpath expressions like this. You'll need to forgive my lack of research on this because i've got no internet except for my phone. But if the new att set only contained locus, couldn't you nevertheless write an xpath2 expression to find Gaby's example using the same kind of wildcard expression you start your last example with but adding an # to the path?

Again, apologies for not being more specific here: I'm working with a miserable email client on my phone. Looks like a smart idea!

-----------
Daniel O'Donnell
University of Lethbridge
(From my mobile telephone)

--- original message ---
From: "Lou Burnard" <lou.burnard at oucs.ox.ac.uk>
Subject: Re: [tei-council] Precision
Date: June 5, 2009
Time: 10:16:52 

Looking more closely at Gabby's proposal for precision has shown up 
something decidedly wrong in TEI P5. Please get a cold towel to wrap 
round your head before reading on.

The <certainty> element has an attribute @locus, which Gabriel wants to 
use to supply the name of an attribute, the value of which he wants to 
indicate uncertainty (or imprecision) about.

In P3 and P4, this attribute had a range of values which included both 
attribute names and some specific literals (e.g. you could say things 
like @locus="#gi" to indicate uncertainty about whether this is the 
right tag, or @locus="#transcribedContent" for uncertainty about the 
content of the element, or @locus="#location" if you felt the start or 
end tags might not be in the right place). At P5, someone (probably me) 
realised that it was too hard to define a datatype for the attribute 
@locus, which would allow both a closed set of literals beginning with 
sharp signs, and an arbitrary collection of attribute names. P5 
therefore has as possible values a set of literals, including "attrName" 
along with the old values, minus their sharps. There is also a rather 
vague statement "if the name of an attribute is supplied it must be 
prefixed by "att." Clearly this cannot work.

In addition to the locus, there is a @target attribute which is used to 
point to the element/s in the document about which uncertainty or 
imprecision is being asserted. Like others such, this attribute is a 
data.pointer, so it could in principle contain an xpath, wrapped up in 
an xpointer, using the rather verbose xpath1 syntax discussed in 16.2.4 
-- e.g. to point to the attribute @foo on the element with xml:id="bar" 
you'd have to say @target='#xpath1(//*[xml:id="bar"]/@foo' vel sim. 
That's OK on paper, but we don't know of any systems that implement it; 
in particular Oxygen doesn't.

We note however that there's no good reason why making an assertion 
about a specific attribute (or, more interestingly, a group of 
attributes) should be handled differently from making one about a 
specific element (or group thereof). And clearly xpath is the right 
syntax for the job. And xpath processors definitely exist! But using 
xpointer in this way seems hopelessly complex...

Further, we note that having @locus indicate things at two completely 
different levels of abstraction is confusing; and that the old method, 
even if it worked, didn't allow you to distinguish uncertainty about the 
appropriateness of the attribute *name* from uncertainty about its *value*.

CONSEQUENTLY after much furrowing of brows, the Oxford team would like 
to propose the following set of changes, applicable to both the existing 
<certainty> and the newly proposed <precision> element

1. The valList for @locus should permit only the following
"name", "value", "startLoc", "endLoc", "location"

(we might say that if this is not specified, "value" should be assumed)

2. An additional attribute @path should be defined. The value of this is 
an xpath2 expression, which should be understood relative to the value 
of @target, which remains as at present a data pointer giving the 
context within which @path is to be interpreted.

3. If there is no @target, then the @path is interpreted relative to the 
document root

This supports the use cases Gabby mentions on ticket #1933198 without 
much difficulty, e.g.

John Smith (bishop <date xml:id=”d002” from=”1753” 
to=”1795”>1753-c.1795</date>)
<precision target=”#d002” path="@to” locus="value" degree=”0.2”/>

It also offers all sorts of other delightful possibilities e.g.

<certainty path="//*/@resp='#lb'” locus="value" degree=”0.2”/>

All in favour?



_______________________________________________
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council