RE: Location terminology

Hi Andrei,

> >> Accuracy is a term that can be very easily misinterpreted.  For a
> >> quantitative concept, the term "uncertainty" is preferred.  NIST
> advises
> >> that there are two many potential interpretations for accuracy and
> they
> >> prefer it to be used only for qualitative statements.
> >>
> >>  http://physics.nist.gov/Pubs/guidelines/appd.1.html

> >>
> 
> I think you are right but maybe this is one aspect where a spec such
> as this can be a little different to an IETF spec. IMHO, the accuracy
> attribute, as we defined it today, is easy enough to understand.

I'm not especially attached to one term over the other.  If consensus is that accuracy is sufficiently unambiguous and well-defined, then I'm happy with that.

> >> In addition, your specification should make some statement about the
> >> expected confidence related to this uncertainty.  You will get a
> number of
> >> opinions on the topic: users and application providers will demand
> the
> >> impossible value of 100%, location providers like lower numbers
> (because it
> >> makes the circle look smaller).  I'd recommend picking between 67%,
> 90% and
> >> 95%, which are commonly used values.  The IETF favour 95% (siding
> with the
> >> users and application providers).
> >>
> 
> To clarify, you are talking about adding some statement in the spec to
> say that the API should return the accuracy at the 95% confidence
> level, right (i.e. you don't mean that we should expose this through
> the API). If this is the case, I am ok with it.

You have it.  Exposing confidence through the API would only complicate it.

Cheers,
Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Monday, 20 October 2008 21:47:45 UTC