[LTER-im] measurmentScale/precision - what definition? howtohandle?
Tim Bergsma
tbergsma at kbs.msu.edu
Wed Aug 6 06:09:00 PDT 2003
David,
my mantra is, "one method: one table". But there will certainly be
times when the convenience of accessing conceptually continuous data in
one pass outweighs the "correctness" gained from breaking it up.
Ideally one might want to do it both ways, to serve different
audiences. I think your advice was appropriate, especially if the
methods changes raise interpretation issues. (But I hope you never have
the chance to comment on our weather data!)
Tim.
David Blankman wrote:
>
> An additional example similar to Barbara's is from Cedar Creek. In Cedar
> Creek they have a 20+ year data table of primary productivity data. Over
> the twenty year period they changed their method for estimating
> productivity twice, that is, they used three different methods for
> estimating primary productivity (different methods for clipping grasses).
>
> My advice to them was to break up the data table so that they would end
> up with three tables. The metadata for each table would be the same
> except for temporal coverage and methodology. Alternatively they could
> just make the changes in methodology explicit in methodStep.
>
> What should the "best practice" be?
>
> David
>
> Matt Jones wrote:
>
> > A short note on Barbara's two-fish-scales problem. This really begs
> > the question "what is an attribute?". I have always felt that an
> > attribute within a table should contain a set of values that can be
> > analyzed uniformly because they were measured using the same methods
> > and conditions. Barbara's example shows that some of her attributes
> > represent measurements that were taken using different methods, and
> > even different instruments. Thus, one might expect that the precision
> > (and other attribute properties) for her measurements is not constant,
> > and that some analyses may be sensitive to her different methods.
> >
> > Personally, I think the right thing in this case is to represent this
> > data as two separate attributes, each of which uses a homogeneous set
> > of methods and instruments. If someone wants to combine the two
> > attributes together for a particular analysis, they can inspect the
> > attribute metadata (e.g., precision), and determine if it would be
> > acceptable for their particular analysis. Combining the measurements
> > using different methods together a priori gives the impression that
> > they are homogeneous and appropriate for all analytical purposes,
> > which is clearly not the case here.
> >
> > Of course, this is probably inconvenient for the investigators who
> > collected the data and know it well. They probably understand the
> > limitations of the data and have a sense of the differences in
> > precision among the values. But, when representing the data for
> > external consumption (e.g., through EML and the web), it would
> > probably be better to be explicit about these details.
> >
> > Matt
> >
> >
> > Tim Bergsma wrote:
> >
> >> 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.
> >
> >
>
> --
> David E. Blankman
> EML Integration Developer
> Long Term Ecological Research Network Office
> University of New Mexico
> 801 University, SE #104
> Albuquerque, NM 87106
> (505) 272-7346 / (505) 272-7080 FAX
>
> -------------------------------------------------
> Long-Term Ecological Research Network Mailing List
> im at LTERnet.edu
> http://sql.lternet.edu/cgi/mailgroups_view.pl?alias_name=im
--
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
More information about the Eml-dev
mailing list