#117 'precision' element needed

[BODARD Gabriel]

In the discussion on the addition of @precision attribute (see #1721365), it emerged that for this to be fully useful, we would need a <precision/> element parallel with the <certainty/> element (with @locus, @target, @degree, etc.). Possibly some discussion of this is needed. (It wouldn't need @assertedValue, for example.) Opening this as a new request to this discussion can be taken forward.

[BODARD Gabriel]

Logged In: YES
user_id=597407
Originator: YES

As a start towards a definition of the <precision/> element, here are my suggestions:

(1) The attributes @degree, @locus, and @target, with exactly the same definitions as currently in <certainty/>. (Should these be made into a class now, rather than given as a one-off definition twice?)

(2a) (Unsure.) Some analogue to the @given and @assertedValue attributes may also be useful. If precision is applied only to @notAfter, for example, what is the *absolute maximum* (as opposed to the conservative maximum) that this value could contain?

(2b) Or perhaps, better, this element should also inherit @min, @max, @atLeast, and @atMost from att.dimensions, so that the precision of the target attribute or quantity can be defined by means of these paramaters rather than simply "high|medium|low".

[Syd Bauman]

Logged In: YES
user_id=686243
Originator: NO

(1) Yes, they should be in a class.

I cannot really discuss (2a) vs (2b), since I have not been able to
find definitions of min=, max=, atLeast=, and atMost=. My instinct,
however, is that (2b) is preferable. But if we want to do this right,
perhaps we should allow expression of the standard deviation?

[BODARD Gabriel]

Logged In: YES
user_id=597407
Originator: YES

Proposal (I think ready for Council):

(1) We should create a new element, <precision/>

(2) This element is a member of "att.ranging" (newly defined class, see #1925125; contains @min, @max, @atLeast, @atMost)

(3) This element is also a member of a newly defined class (?"att.qualifier") containing @degree, @locus, @target (to which <certainty/> will now also belong)

(4) define one new attribute, @stdDeviation, for recording the standard deviation of a number, range, or approximation. (data.numeric is probably appropriate for this attribute.)

[Paul Schaffner]

Added by Gabriel Bodard via email 31 March 2009:

Proposal:

This FR proposed the creation of a new element, <precision/> for use in
those cases where the precision of a date or dimension or other
measurement is more complicated that can be expressed by the simple
@precision attribute. (This is a direct parallel to the <certainty/>
element, which handles cases that are too complicated for simple @cert.)

This was first discussed by the group in Galway, and since taken further
by James C. and myself, and the recommendation is as follows:

(1) Creation of a new element, <precision/> (empty element);

(2) element inherits global attributes and those from att.dimensions
(@min, @max, @atLeast, @atMost are the essential ones);

(3) Create a new attribute class (“att.qualifier” vel sim.) with the
attributes @degree, @locus, @target (currently defined ad hoc for
<certainty/>;

(4) define new attribute @stdDeviation for <precision/>, with datatype
numeric.

Examples of usage:

(A)
<date xml:id=”d00001” notBefore=”0014” notAfter=”0064”>Within approx 50
years of the death of Augustus</date>
<precision target=”#d001” locus=”notAfter” degree=”low”/>
<precision target=”#d001” locus=”notBefore” degree=”high”/>

(B)
John Smith (bishop <date xml:id=”d002” from=”1753”
to=”1795”>1753-c.1795</date>)
<precision target=”#d002” locus=”to” degree=”low”/>

(C)
Each column has a minimum of 10 characters width and a maximum of c.25
(I know this is clumsy, but people do say this sort of thing):
<measure type=”count” min=”10” max=”25” xml:id=”m001”>10-c.25</measure>
<precision target=”#m001” locus=”max” degree=”low”/>

(The dates are the really compelling use-case for this... partly because
you used to be able to do something similar in Master with @notBefore,
@notAfter, and @exact=’both|notAfter|notBefore|none’.)

((Someone more comfortable with statistics than me can probably come up
with an example using @stdDeviation. Possibly James, who I think
convinced me when we discussed this.))

[Lou Burnard]

This seems plausible, but the Council wants a bit more time to consider it.

[Lou Burnard]

1. split @min @max @atLeast @atMost out of att.dimensions into new class att.ranging; made att.dimensions member of this new class
2. Realized that @locus was seriously broken at P5, so posted the following set of proposals to Council for approval:

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?

[Lou Burnard]

Implemented at revision [r6590] or thereabouts