#585 Precision element missing att.ranging class

AMBER
closed-fixed
nobody
None
6
2014-09-03
2013-07-04
No

When we created the <precision> element a few years ago (see FR 117) it was proposed and agreed to include in its model the attribute class att.ranging. This is to allow the expressing of maximum and minimum values for uncertain or imprecise spans of dates, measurements, etc.

To use Thomas Carlson's example as an illustration, a <state> in the person entry for the patriarch Shem'on, whose tenture began some time between 1382 and 1430 and ended sometime between 1444 and 1477, might be encoded as:

<state from="1382" to="1477">
   <precision match="@from" atLeast="1382" atMost="1430"/>
   <precision match="@to" atLeast="1444"  atMost="1477"/>
   <p>Catholicos-Patriarch of the Church of the East.</p> 
</state>

This seems like a simple omission at the time of the creation of this element, and I propose it should be added as a bug-fix as soon as possible.

Discussion

  • Lou Burnard

    Lou Burnard - 2013-07-23

    The proposal is to add <precision> to the class att.ranging with the semantics that membership in this class is thereby transferred to the node matched by the @match attribute (we're not saying that the precision itself is what ranges). It's clear (and useful) how that works in the above case; it does also permit nonsense if, for example, the node matched by @match is not a datable element. If we implement this, should we perhaps warn against potential for incoherence?

     
  • BODARD Gabriel

    BODARD Gabriel - 2013-07-23

    Agreed (although of course not only datable elements, but also measurable and countable ones can be given precision values; I've changed the example above to use @atLeast/@atMost rather than notBefore/After, which matches the truth of what att.ranging actually includes.).

     
  • Lou Burnard

    Lou Burnard - 2013-07-23

    Hmm, now I'm even more confused. Suppose I want to supply a precision value for something which is at least 0.4 and at most 0.7: wouldn't I do that with
    <precision match="#whatever" atLeast="0.4" atMost="0.7"/>
    How do I distinguish that case from the one you give above, where the @atLeast and @atMost values relate not to the precision but to the values indicated by @match?

    In general I'm suspicious of/confused by attributes which seem to be qualifying other attributes rather than the element they are attached to.

     
  • Hugh A. Cayless

    Hugh A. Cayless - 2013-07-23

    I like this proposal very much, as it makes it possible to represent accuracy in a quantifiable way, as opposed to the shrieking insanity that is @degree.

    Lou's example confuses me a bit. If an element is a member of att.ranging, you'd put the @atLeast/@atMost on that element. <precision> would come in if the upper or lower end of the range was itself fuzzy (+/- .05, for example).

    A small quibble: in Thomas's example, @match should be '../@from' and '../@to'.

     
    • BODARD Gabriel

      BODARD Gabriel - 2013-07-23

      Funny, I first posted that example with the @match attribute as you give it here, and James (rightly) corrected me to point out that in the absense of @target, @match is assumed to refer to its parent element, so ../ would be redundant.

       
      • Hugh A. Cayless

        Hugh A. Cayless - 2013-07-23

        Is that right? I read the note at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html to say that if neither @target nor @match is present, then the context is assumed to be the parent. Also, the example given in @match uses the parent axis, so it must be wrong, no? I'm fine with the default context being the parent, but I think we have a bug in the definition if that's the case.

         
        • BODARD Gabriel

          BODARD Gabriel - 2013-07-23

          yeah, looking at it again I remember why I was confused. The definition is unclear, and the examples don't quite match the more likely interpretation. That needs clearing up. (In another ticket, though. :-) )

           
  • Lou Burnard

    Lou Burnard - 2013-07-23

    I think "shrieking insanity" is a little inaccurate, not to say unparliamentary language . @degree is a perfectly reasonable way of indicating a precision value, for example if you are talking about an average rainfall value which is accurate to within plus or minus 40 % it has a precision degree of 0.4. What's insane about that?

    This proposal seems to be adding attributes to an element (<precision>) and invoking a special rule which says that the attributes don't apply to that element, but instead to the thing this element is pointing to (by means of its @match attribute). My concern is the potential ambiguity introduced by this departure from normality, which says that attributes qualify the element that bears them. Sorry if that seems "shriekingly insane".

     
    • Hugh A. Cayless

      Hugh A. Cayless - 2013-07-23

      Lou, I meant in no way to impugn the sanity of your argument. I'm not sure I agree with the principle, but it's perfectly consistent and in no way at all mad. I do think @degree itself is a very bad thing.

       
  • BODARD Gabriel

    BODARD Gabriel - 2013-07-23

    Surely this is how all the attributes on <precision> work, viz that they refer to the element, attribute or other node that is being pointed to by @match, not to the element itself. (It's also how @precision works, for that matter, on other elements; it refers not to the element itself but to the dating attribute(s) on that element.)

    (I'd also add that this is not a new proposal--it is precisely the proposal that was agreed upon in 2009, but this part of it was not fully implemented. My fault for not noticing at the time, of course, but this "special rule" has always been core to the way the <precision> element was envisaged.)

     
  • Hugh A. Cayless

    Hugh A. Cayless - 2013-07-23

    I apologize for the strong language, but I really do think, and have thought for a long time that @degree is crazy. For starters, +/- 40% of what? The rainfall amount? Nobody expresses accuracy in that way. You might, however, say 200 inches +/- 5 inches. Let's stare into the abyss for a moment and look at the first example of <precision> at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#CEPREC

    <date xml:id="d001" notBefore="0014" notAfter="0064">About 50 years after the death of Augustus</date>
    <precision target="#d001" match="@notAfter" degree="0.3"/>
    <precision target="#d001" match="@notBefore" degree="0.9"/>
    

    So @degree on that first one means +/- 30% of the year 64? What does that even mean? It would be vastly better to say, in effect, "this number might be off by up to 10 years in either direction". This is what I mean by it being quantifiable. I can't do anything with degree="0.3".

     
    • Hugh A. Cayless

      Hugh A. Cayless - 2013-07-23

      Just to follow up: I don't want my hatred of @degree to derail discussion of this bug. I was just expressing my enthusiasm for the proposed addition, which makes <precision> way better.

       
  • Lou Burnard

    Lou Burnard - 2013-07-24

    I'm not proposing we go back on the earlier decision: just that we make a bit clearer in the documentation what exactly it means. It also seems to me that if there is really strong feeling against the use of @degree, then removing or deprecating it would make clearer the semantics of the att.ranging attributes when they are used on <precision>

     
    • Hugh A. Cayless

      Hugh A. Cayless - 2013-07-24

      Absolutely agree. Getting att.ranging into the content model would be a necessary prerequisite for deprecating @degree on <precision>, which I will propose immediately after we agree to fix this bug (if someone else doesn't get there first).

       
  • BODARD Gabriel

    BODARD Gabriel - 2013-07-24

    Added att.ranging to elementSpec at revision [r12472]. As noted, there needs to be more discussion, both on this element and in the chapter on dating, to explain and exemplify the use of these attributes. I have not done anything on this yet.

     

    Related

    Commit: [r12472]

  • Syd Bauman

    Syd Bauman - 2013-11-12
    • status: open --> closed-fixed
     
  • Syd Bauman

    Syd Bauman - 2013-11-12

    Closed by subcommittee at Council face-to-face 2013-11-12, with request to Gabby to open another ticket on clarifying the documentation as per his 07-23 comment.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks