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 *
*******************************************************
Received on Wed Mar 27 2013 - 14:23:35 GMT
