[tei-council] Precision
Lou Burnard
lou.burnard at oucs.ox.ac.uk
Fri Jun 5 12:16:46 EDT 2009
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?
More information about the tei-council
mailing list