[LTER-im] measurmentScale/precision - what definition? how to handle?

Tue Aug 5 16:57:33 PDT 2003

One of my earlier grad student jobs in archaeology was as a crew chief on a
project that hired local Navajo workers to do the excavation. One of my
crew, John, would measure the dimensions of his excavated pits by holding
the reel near one edge, pulling out a length of tape and carefully read out
the value where the tape crossed the pit edge . He never really looked where
the end of the tape was as he was concentrating on the reading. The
precision of these measurements seems to me to be meters to the nearest
centimeter - every time John pulls an arm's length of tape out, he will get
that same reading. The accuracy (based on my rather subjective assessment of
the length of John's left arm relative to the size pits we dug) was
something like +/- 10 centimeters, but like Barbara's fish, tended to
increase as the width of the pits exceeded his reach.

This doesn't contribute anything useful here - just my fond memory of using
it years later when I taught statistics in athropology as an example of
precision versus accuracy. 

Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental-Studies
Arizona State University

-----Original Message-----
From: Scott Chapal [mailto:scott.chapal at jonesctr.org] 
Sent: Tuesday, August 05, 2003 7:32 AM
To: eml-dev at ecoinformatics.org
Subject: Re: [LTER-im] measurmentScale/precision - what definition? how
tohandle?

eml-dev:

While I don't disagree with what Matt just wrote, I have a slightly
different point:

I thought EML was capturing 'Measurement Precision' (or what Wade called
accuracy).  If this is really measurement precision, I don't think the (old)
definition is so bad (with a slight enhancement):

<doc:description>

The precision element represents the precision of the measurement (the
smallest interval in which measured values are distinguished), in the same
unit as the measurement. For example, for an attribute with unit "meter", a
precision of "0.1" would be interpreted as precise to the nearest 1/10th of
a meter, and a precision of "1" would be interpreted as precise to the
nearest 1 meter.

</doc:description>

It could be that the way EML precision and unit have been co-defined might
contribute to usage confusion.  In the definition above, .1 meter could be
represented as precision 1 and unit 'decimeter' (or 10 and centimeter).  We
have two sliding parameters in unit and precision in which the same result
can be expressed in many ways.

But clearly, there is a larger problem too.  The apparently wide-spread
confusion of precision with accuracy highlights a consequence of informality
in data management.  To take data that have been collected under inspecific
criteria or non-rigorous QA and to then try to extract EML-compliant
metadata, is an exercise in frustration.  But it is a useful excercise,
because it shows the true utility of EML in the long run -- to help us
understand what is really needed for data reuse.

Associating 'accuracy' with calculated values is not the same as associating
precision with measured parameters.  It's easier and more defensible to do
the latter in the context of metadata -- so that means that the data which
are documented and archived should be as close to the original measurements
as possible.  Derivative representations of the data (calculated values)
should be reproducible from the metadata, but probably not incorporated into
the data being archived.  Encouraging the archival of original measurements
as 'best practice' potentially has the side effect of simplifying the
proliferation-of-units conundrum as well.  Many of the esoteric units which
have been proposed are obviously calculated values and not original
measurements.  Unfortunately, data which are contributed are often massaged,
summarized or cleaned-up (whatever that means).  I would be satisfied to be
able to make a cogent statement about simple measurement precision, never
mind accuracy.

One problem with making precision optional is that when calculated values
are represented, and the 'original measurements' are gone, the precision
implied by the data can be misleading (ie. more precise than warranted).
And data archaeology efforts to derive the correct precision from calculated
values are not necessarily trustworthy - as David has found out.  Requiring
precision forces an 'educated guess' at the time EML is generated from the
data.  It might be preferable to have it guessed at then, than to leave it
to a naive future end user.

My .02 $.

-Scott

BTW - I love that 1.25" example.  English units (mis)represented in decimal
precision.  Oh brother.  (We do that here too, mm is just too....metric,
apparently!)  Don't know exactly why...it can't be that XML is holding us
back from representing it as ¼" precision can it? :)

Tim Bergsma <tbergsma at kbs.msu.edu> writes:

> Peter, others,
> 
> regarding the previous comment...
>  
> > However we go, its obivous that we need to re write the definiation 
> > of precision since, as David points out, its doesnt define the term 
> > precision. - is it significant digits or an iterval? and does that 
> > refer only to the mimumum reported digit or interval or is it a 
> > statement of accuracy?
> 
> I agree.  We need to rewrite the definition.  It is interval, not 
> significant digits, because significant digits is just a special case 
> of interval, and we need to stay general.  It is not a statement of 
> accuracy OR statistically qualified "precision", because there is no 
> universally-received definitions for these things, and no way to 
> attach a custom definition to the precision element.
> 
> Tim
> 
> P.S.  This doesn't solve Barbara's two-fish-scales problem.  Alas!  I 
> fear it is unsolvable.  Perhaps she should just report the worst of 
> the two relevant precisions, or split the table.

-- 
\SEC
_______________________________________________
eml-dev mailing list
eml-dev at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/eml-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030805/c9e93a53/attachment.htm