[CF-metadata] standard names for variables in 'raw engineering' units

From: John Graybeal <graybeal>
Date: Thu, 12 Mar 2009 11:59:57 -0700

On Mar 12, 2009, at 10:17 AM, Karl Taylor wrote:

> Perhaps I'm not following what's being proposed here, but I'm
> against expanding the nature of the standard name from a definition
> of a physical quantity, to something that includes an indication of
> its potential uses (which admittedly would help in "discovery"
> searches).

The initial proposal was to allow the definition of the observational
physical quantities that are measured/stored in units that are not non-
UD_Units. Example: sea_water_temperature_raw. No indication of
potential uses there, only that the canonical units criterion is not
satisfied.

Two other standard name classes were introduced in the discussion:
physical quantities related to the instrument, and non-physical
quantities related to the instrument. (Note the first class is
already in CF: temperature_of_sensor_for_oxygen_in_sea_water.) While
I don't think the standard name includes potential uses in either of
those cases, I suggest we discuss on a separate thread whether these
two classes are appropriate for CF.

On Mar 12, 2009, at 10:13 AM, Nan Galbraith wrote:

> At some point, it becomes meaningless to use a standard, if you
> are storing and presenting data in a form that can't be used without
> further processing and without a lot more information.


This is not true. It is extremely useful, as described in the
original email, to be able to find ALL measurements that may be
brought to bear upon a particular science problem. The fact that
additional processing is necessary may be inconsequential to the
person looking for the data. (And of course, some may add the
necessary processing information in the form of other auxiliary
metadata. It's just CF doesn't have a standard way to do that yet,
which is fine.)

> Use cases showing a need to store 'partially transformed' data or
> 'complex
> data in alternate formats' using standard names and requiring new
> kinds of
> units would be helpful.

If by use cases you mean existing practices, I do not have use cases
for either of those particular examples in hand, though I have dealt
with them in the past. They were offered for perspective only.
(I do have a number of non-UDunit difficulties, but haven't compiled
the list yet; I think that topic needs to be on another thread anyway.)

John
Received on Thu Mar 12 2009 - 12:59:57 GMT