Hi All?
"I'm on fire, put me out!!!"
That is my appeal to bring the conversation back to my specific question that remains. At this point, I want to do only what the standard says to do. I agree with what seems to be the general mood (though not universal) that clarity is needed and maybe some changes, and I point out that questions like this are precisely why we at NODC decided to come up with our templates and examples. I want to help others in the ocean data world make CF-compliant netCDF? not almost-compliant CF-netCDF. What I personally think about the standard doesn't matter for that purpose, though of course it does matter in discussion forums like this? so, if I can get a clear answer on this remaining practical question it would be great:
== start quote
[snip] Now the third case is where there exists a relevant standard_name modifier, for example, for the standard error of the mean:
float t_se(time, depth, lat, lon) ;
t_an:standard_name = "sea_water_temperature standard_error" ; // Use the physical parameter's standard_name plus modifier, following Jonathan's comment
t_an:long_name = "Standard Error about the Statistical Mean Sea Water Temperature" ; // Expanded long_name following Steve's comment
t_an:comment = "The standard error about the statistical mean Sea Water Temperature in each grid-square at each standard depth level" ; // just highlighting changes compared to our existing draft
t_an:cell_methods = "area: mean depth: mean" ; // Is this correct?? Since we have a standard name modifier, and no cell_methods string for standard error?
t_an:grid_mapping = "crs" ;
t_an:units = "degrees_celsius" ;
t_an:FillValue = 9.96921e+36f
So, my question arises in this last example, where a standard name modifier exists. I guess this is the part I don't understand?. is there no reference to cell_methods for the time dimension in the standard error variable t_se?
== end quote
If I can get the answer to the above, Tim and I can move on with this data set.
Now, when it comes to my ability to explain the standard and those choices to our data producers, I would like an answer to the other question that I had posted:
==
? why is there a standard_error standard_name modifier but not one for standard_deviation?
==
I still don't really get that. If the answer is simply "for unknown historical reasons" that is ok? if it has to do with the statistical nature driving the placement of a term in cell_methods or in standard_name_modifier that is ok to? just want to know :-)
I have learned through all of this to think about standard_name differently? though I was aware of the modifiers and of cell_methods, I do believe I was stuck on the idea that standard_name alone (possibly with a modifier) defined the content of the variable? I guess cell_methods seemed to me like a second-order thing, to help really understand what was in those cells.
Thanks,
Ken
On Mar 27, 2013, at 5:38 PM, John Graybeal <graybeal at marinemetadata.org> wrote:
>
> On Mar 26, 2013, at 18:08, Jonathan Gregory <j.m.gregory at reading.ac.uk> 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.
>
> Or that people threw up their hands and said "This just doesn't work, I'm going to ignore it/wing it/make up my own answer."
>
> Having watched people do that re some variable names, and yes, done it myself on occasion, this path should not go unconsidered.
>
>>>> 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.
>
> So what are the standard name modifiers doing in the mix of standard names, since they clearly do more than identify the geophysical quantity? Or perhaps that is wrong-headed to consider them 'part of' the standard name....
>
> The first time I read the whole standard name description, this confused me, and it has not become less confusing since. I just looked at the three references to standard name modifiers and I'm still lost.
> For example, a variable may contain data to which spatial or temporal operations have been applied. Or the data may represent an uncertainty in the measurement of a quantity. These quantity attributes are expressed as modifiers of the standard name. Modifications due to common statistical operations are expressed via the cell_methods attribute (see Section 7.3, ?Cell Methods? and Appendix E, Cell Methods ). Other types of quantity modifiers are expressed using the optional modifier part of
> the standard_name attribute.
> A standard name is associated with a variable via the attribute standard_name which takes a string value comprisedof a standard name optionally followed by one or more blanks and a standard name modifier
> a variable with a standard_name attribute must have units which are physically equivalent (not necessarily identical) to the canonical units, possibly modified by an operation specified by either the standard name modifier (see below and Appendix C, Standard Name Modifiers ) or by the cell_methods attribute
>
>> <snip>
>> I do agree there is some conceptual similarity between cell_methods and standard_name modifiers, though they're not the same.
>
> Does the above text delineate the difference in your mind? (It seems to me that at least 3 of the modifiers are mathematical, at least two of them are statistical, and one of them involves statistical operations on the data. But my mileage may vary...)
>
> Is there a way to more clearly state the nature of the difference? If not, unification could be helpful.
>
>> If they were to be unified, I think it would be better to do that by moving the modifiers into the cell_methods somehow.
>
> I concur that moving the modifiers into the cell_methods would be more crisp than the other way around, even if intuitively I agree wholeheartedly with Nan's point about different units. Everyone can learn, in time, that the standard name is only a *part* of the description of the attribute; and they have to learn that anyway with cell_methods in play.
>
> It is a little confusing that standard names don't have to have the same unit base if other attributes come into play. Makes one wish for a marker in the standard name, like a trailing _modified or something.
>
>> When modifiers were first introduced, some people objected to them because they confused the purpose of the standard_name attribute.
>
> QED.
>
>
> ---------------
> John Graybeal
> Marine Metadata Interoperability Project: http://marinemetadata.org
> graybeal at marinemetadata.org
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Kenneth S. Casey, Ph.D.
Technical Director
NOAA National Oceanographic Data Center
1315 East-West Highway
Silver Spring MD 20910
301-713-3272 x133
http://www.nodc.noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130329/bba7be5e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook.png
Type: image/png
Size: 533 bytes
Desc: not available
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130329/bba7be5e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RSS.png
Type: image/png
Size: 1654 bytes
Desc: not available
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130329/bba7be5e/attachment-0003.png>
Received on Fri Mar 29 2013 - 07:26:23 GMT
