Dear Lorenzo
Thank you for your email.
> I think the cell-methods mechanism has a partial overlapping with netCDF-U, in that it can account for (some of the) UncertML Summary Statistics concepts. However, it does not currently address Distributions and Samples.
> We could think of extending it, but we preferred to introduce a new mechanism, based on the standard URI syntax and RDF semantics.
>
> On the other hand, the cell-methods mechanism is arguably more fine-grained than netCDF-U, allowing to express different methods on multi-dimensional variables, particular as far as the semantics of dimension intervals is concerned.
Yes, I agree with your last point. An important aspect of cell_methods is that
it relates to particular axes. Describing a quantity just as a "variance", for
instance, can be rather vague: it may be necessary to know if it's a variance
over space, over time or over ensemble members, for example. Possibly you
could consider including your URIs and some other extra information as comments
in cell_methods. These would be legal but unstandardised as far as CF is
concerned, but you could standardise them in your convention e.g.
double biotemperature_variance(lat,lon);
biotemperature_variance:units = "degC"; // shouldn't it be degC^2 for a variance?
biotemperature_variance:cell_methods="realization: variance (ref
http://www.uncertml.org/distributions/normal#variance)"
The cell_methods here refers to realization as a standard name, which is
allowed even though realization isn't a dimension. If you do have a dimension
for realization, as in one of your examples, the coordinate variable for that
dimension could have a standard_name="realization" attribute. If the variance
was over an existing dimension, that could be used e.g.
double biotemperature_mean(time,lat,lon):
biotemperature_mean:units = "degC";
biotemperature_mean:cell_methods="time: mean (ref
http://www.uncertml.org/distributions/normal#mean)"
Of course, this will only work for those statistical methods which are
allowed by cell_methods. However, you could propose others to include in
Appendix E if they are ways of computing statistics like those.
Looking at your examples, I wonder why you have, for instance
lon:_CoordinateAxisType = "Lon";
What is the need for this new attribute? CF already offers these two methods
to indicate such an axis:
lon:axis="X";
lon:standard_name="longitude";
and in addition, the units of degrees_east imply that it is longitude.
Best wishes
Jonathan
Received on Thu Dec 08 2011 - 01:29:20 GMT
