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 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata