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

[Scott Chapal]

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