Hi Jonathan -
I agree that cell methods are useful, and that we can't have all the
information
about a variable in the standard name. There's a *huge* difference, though,
between a mean/median and a standard deviation/variance, (even a maximum).
Yes these should be described in cell methods, but if the quantity in
the data
variable is not a representation of the geophysical concept described by
the standard
name, a standard name modifier IS also needed. At least, that's how I'd
want to
treat this kind of data.
I don't think the standard deviation of the temperature of sea water is
really a
geophysical property; it's a mathematical concept, while a temperature
value
represented as a mean is still a temperature.
I would like to point out, again, that CF has been like this for 13 years.
While that doesn't mean it is perfect, it probably means it's not too bad.
I'd like to say that I was in primary school 13 years ago, but I'd be
lying. Instead, I
have to admit that this discussion just didn't seem to apply to my data
at that point,
so I cheerfully ignored it. Now all I can say is that just because it's
legal, doesn't mean
it's 'right'.
And, I'm still curious if it is a widespread practice to share data
where an unmodified
standard name is used for a data variable that does not contain the
geophysical
property implied by that name. I guess I could go check out some
thredds servers
and find out ...
Cheers - Nan
On 3/26/13 12:08 PM, Jonathan Gregory wrote:
Dear Steve and Nan
I would like to point out, again, that CF has been like this for 13 years.
While that doesn't mean it is perfect, it probably means it's not too bad.
It's alarming to think people can use an unmodified standard name like
sea_water_temperature for a variable that is in fact a standard deviation
or an error. I'm very curious to know if this is a widespread use of cell
methods, because it seems so ... wrong.
My personal viewpoint: There's a strong case to be made that the
string assigned to the standard_name attribute, whatever it is,
should accurately describe what the variable is. If we do not
follow this principle we know that mistakes and frustrations for end
users will be the result. It will be cold comfort to blame the
users and software developers. Expanding the standard_name modifier
list may provide a solution that does not cause proliferation in the
length of the standard names list.
I disagree. The standard name is just one component of CF metadata. Its purpose
is to identify the geophysical quantity. Temperature is the same geophysical
quantity, regardless of whether the data is mean temperature, maximum
temperature, median temperature, 99-percentile of temperature, standard
deviation of temperature or variance of temperature. I guess it's because
standard names are so useful that there is a temptation to think that all
the essential metadata should be contained in the standard name!
However, I do not think one should expect all the metadata to be contained
within a single string. If this is really a problem, then we should make sure
some solution like that proposed by Cecelia in trac ticket 94
https://cf-pcmdi.llnl.gov/trac/ticket/94
is added to CF, and encourage people to include it in their data. This would
be convenient for data discovery, as well as for the purpose that motivated
it (exchanging data between submodels). Please add your support and comments
to that ticket.
"Standard deviation of temperature" is too vague. It often causes confusion,
even in publications, about whether the author means a temporal variation or a
spatial variation, for example. That's why it's in cell_methods, principally,
where it is associated with a dimension, and hence made precise.
I do agree there is some conceptual similarity between cell_methods and
standard_name modifiers, though they're not the same. If they were to be
unified, I think it would be better to do that by moving the modifiers into
the cell_methods somehow. When modifiers were first introduced, some people
objected to them because they confused the purpose of the standard_name
attribute.
Best wishes
Jonathan
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
