[Fwd: precision ---- yet again]

[Tim Bergsma]

[Soapbox]
I'm unashamedly lobbying for defining precision as "resolution", as
explained in my last email on the topic.  I see the practicality of
making it optional, especially because there are cases where it will be
unknown, or will vary among records.

If precision is defined operationally as resolution, i.e. "the smallest
interval that the measurement method distinguishes, reported in the same
units as the attribute", then Barbara's problems go away.  Both accuracy
and precision, as reported in airport_met.xls, are statistical in
nature, and should be relegated to the eml-accuracy element where the
test can be adequately explained.  It's worth noting that
airport_met.xls does not adequately explain the tests.  Indeed, most of
us involved with weather data probably routinely ingest the claims of
the sensor manufacturers without feeling a need to know how the
estimates of accuracy and precision were generated.  MAX_REL_HUM, for
example, probably means to claim that repeated observations of constant
humidity below rh90 have a coefficient of variation of 0.03 (unitless: 
standard deviation divided by the mean) but the mean of many such
observations, less the true value, then divided by the true value, is
between 0.0001 and -0.0001, with probablility 0.95.

Resolution, however, is a property of how the observation is made, not
of how repeated observations are distributed (nor of how the observation
is stored).  In the case of MAX_REL_HUM, the method (sensor, datalogger,
A/D converter, logger program, download cycle) generates values between
0 and 1, in 0.001 increments.  E.g., the datalogger output for REL_HUM
might be 0.615, or 0.616, but cannot be 0.6155.  Thus, eml-precision is
0.001, in the same units as the attribute.  In a deci-centric world,
this will often look like just a matter of counting decimal places, but
in significant cases it is not. 

Tim.  



Matt Jones wrote:
> 
> Here's some more input on the precision issue from Barbara Benson.
> Babrbara's examples require us to be able to express precision as a
> percentage, and to have non-constant precision that varies across its
> range or is tied to another variable (e.g., precision of radiation
> measures depends on temperature).
> 
> It would be nice to work this stuff out.  I think the first step is to
> simply define the current field and make it optional so that it no
> longer prevents the submission of metadata [bug 1124]. Then we should
> consider these more complicated cases.
> 
> Matt
> 
> [bug 1124] http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1124
> 
> --
> -------------------------------------------------------------------
> Matt Jones                                     jones at nceas.ucsb.edu
> http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
> National Center for Ecological Analysis and Synthesis (NCEAS)
> University of California Santa Barbara
> Interested in ecological informatics? http://www.ecoinformatics.org
> -------------------------------------------------------------------
> 
>   ------------------------------------------------------------------------
> Hi Matt,
> 
> It was great to interact with you and the other SEEK folks last week.  I am
> now trying to get some NTL metadata to David Blankman for Metacat.  I
> wanted you both to see the kind of information I got back from our field
> tech and site manager when I asked them to provide precision information
> (see attached Excel file please).  They also addressed accuracy.  I think
> what they provided is useful information that should be captured even
> though EML2 would not allow it to be entered in the precision field.  There
> seem to be two different cases that don't fit:  precision given as a
> percent and precision information given in a form that might only be
> captured in a string field.  Please let me know what you think.  Feel free
> to pass this along to the EML developers.
> 
> Barbara
> 
> Barbara Benson
> Center for Limnology, University of Wisconsin-Madison
> 680 N. Park St.
> Madison, WI 53706
> 
> (608)262-2573
> fax: (608)265-2340
> 
>   ------------------------------------------------------------------------
>                                                Name: precision example airport_met.xls
>    precision example airport_met.xls           Type: EXCEL File (application/msexcel)
>                                            Encoding: BASE64
>                                     Download Status: Not downloaded with message

-- 
Tim Bergsma
LTER Information Manager
W.K. Kellogg Biological Station
Michigan State University
Hickory Corners, MI   49060
269/671-2337
tbergsma at kbs.msu.edu
http://lter.kbs.msu.edu