On Mar 12, 2009, at 4:15 PM, Robert Muetzelfeldt wrote:
> What is the actual (scientific) value of having units associated
> with raw measurements?
(see below)
On Mar 12, 2009, at 4:19 PM, Karl Taylor wrote:
> Can you remind me what you have proposed in place of
> ctd_fluorometer_voltage for the example under discussion? Would
> "fluorometer_reading" be an appropriate standard name, and you could
> attach a units attribute indicating the measurement is in volts.
> (The thing being measured is clearly *not* temperature, even though
> you might be able to estimate the temperature based on the
> measurement, so I see no reason to include temperature in the
> standard_name.)
Hmm, 'reading'. Might work. Or 'measure'.
I don't know what Roy's fluorometer measures (example from which the
'ctd_fluorometer_voltage' notion came), but ours measures fluorescence
among other things (CDOM, chlorophyll). I am picking the WetLabs ECO-
FL fluorometer for this example (I apologize if I get any of the
subtle details wrong here).
The instrument can produce raw values corresponding to the
fluorescence signal. This value is in counts (in digital mode), or
the instrument can produce volts (in analog mode). In answer to the
first question above, it is useful to know whether the value in the
netCDF file is the volts or the counts. [1]
The instrument can also produce what it calls 'engineering units' in
micrograms/liter for the signal. (To do this, it uses calibration
values that have been entered beforehand.)
So while my scientific expertise is a little uncertain here, one of
the conversions can be for chlorophyll, so let's use that example: the
first standard name will be
concentration_of_chlorophyll_in_sea_water_reading (or _raw, or
_variant_units)
and the second will be
concentration_of_chlorophyll_in_sea_water
I would *not* use the name of the instrument (or platform) in the
standard name. This instrument, for example, can measure and report
multiple phenomena (even within one record). As the existing standard
names largely correspond to geophysical properties, this proposal
makes it possible to name preliminary measurements of those
geophysical properties. So the names should still correspond to the
geophysical properties in question.
John
[1] I appreciate that we still need a scale factor and offset to get
from *either* counts or volts to the science units, so the science
application is less immediate. But a key point is that if I have a
copy of the metadata produced from the instrument before the relevant
deployment, that metadata will give me the information that lets me do
that conversion, recovering the science data -- but I need to know
whether to convert volts or counts. (Though you might argue that's
still a bad example, because I could inspect the values for a decimal
point with this particular instrument -- but the volts/counts
difference is deterministic, _and_ can even be automated in
appropriately designed systems. )
>
>
>
> John Graybeal wrote:
>> Thank you all for all your thoughts on this.
>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 03/12/09 9:57 PM >>>
>>> I don't really know what it is, of course, but it sounds like it
>>> could have a standard name of ctd_fluorometer_voltage and units of
>>> V. <snip> Here, the quantity being named relates specifically to a
>>> means of measurement, not to the final product.
>> I must quibble. The quantity being named relates specifically to
>> the _units_ of the measurement, not the means of measurement. And
>> the reason this (new standard name) must be done is that Standard
>> Names are specifically tied to units (via the canonical units
>> requirement), and so the strange unit forces a different standard
>> name.
>> And so for purest reflection of meaning, we are back to something
>> like 'variant_unit' (instead of 'raw'). I discourage incorporating
>> the unit in the standard name ('voltage' in Jonathan's example)
>> because there is no way to know if *this* temperature_voltage
>> variable is interoperable with *that* temperature_voltage, unless
>> attributes for conversion to canonical units are provided. So the
>> units attribute can name the units, and this standard name should
>> just make clear that the units are not canonical units.
>> And, can we make it an item in appendix C, please?
>>> What are example of non-udunits? V is a udunit, all right. Perhaps
>>> a non-udunit
>>> is just a count of something? Does that need units? It could
>>> simply be
>>> regarded as dimensionless.
>> Addressed in other thread; no non-udunits have been identified so
>> far relating to raw geophysical data.
>> John
>> --------------
>> John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
>> Monterey Bay Aquarium Research Institute
>> Marine Metadata Interoperability Project: http:// marinemetadata.org
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Thu Mar 12 2009 - 18:59:20 GMT
