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

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 22 Apr 2009 08:33:59 +0100

Dear John

Thanks for your helpful email and summary.

(a) Regarding

> After a suitable opportunity for general comment
> on the latest emails, can the moderators weigh in with suggestions to
> resolve each issue one way or the other, or to create a TRAC proposal
> discussion?

I would like to point out that there are no moderators available. Those who
are discussing it are responsible. CF doesn't have any other resources to
resolve such issues. We can move to trac if you like. If there are specific
proposals to amend the convention, trac is the way to make them.

(b) Unprocessed/uncalibrated geophysical properties. I think this is my
raw data. We could propose a standard name modifier for it. Since that has
to specify a particular units transformation, I think the obvious options are
dimensionless raw data (units not specified), or raw data with the same
physical dimensions as the geophysical quantity. If both are useful, separate
modifiers for each of them could be proposed. Nan also mentioned QC data;
that is certainly a good purpose for standard_name modifiers and we already
have some defined in the convention for that. Both you and Roy think that
the modifier would be better if it was attached with some non-blank character
to the rest of the standard name. That could be proposed as a change to the
convention (although we'd have to keep blank-separation for backward
compatibility). I would argue that if we do that it should be some character
which we would prohibit from being used anywhere else in a standard name.
For instance, we could use % for this purpose. I think hyphen would be
confusing as it looks too much like underscore.

(c) Sensor quantities. I don't think we should completely rule out defining
standard names for these. For example, I think the "platform" names in the
standard name table are well-defined and useful. However, I quite like your
idea of defining generic standard names. If they are going to be standard
names, they have to have canonical units, so they cannot be as vague as "sensor
property". However, we could define a standard name for sensor_temperature,
for instance. That would replace temperature_of_sensor_for_oxygen_in_sea_water,
in your suggestion, I think. The more specific description would no longer be
in the standard name. However, to some extent this just postpones the issue.
Is it necessary to *standardise* the extra information, or could each dataset
just record it in some informal way, for instance in the long_name? If that
would be sufficient, it would be far easier. Deciding standards is a time-
consuming business, as we all know.

Best wishes

Jonathan
Received on Wed Apr 22 2009 - 01:33:59 BST