Overall, I think that the general approach of using ancillary variables and cell methods is a good one.
There was considerable discussion around the topic of "standard name modifiers or cell methods?" in [2011](https://urldefense.us/v3/__http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/thread.html__;!!G2kpM7uM-TzIFchu!gLR5wmXEkR9EbaC2aF5t_00SHATOFr3MoE9rj6HVAJPUrdvl_Kv0xkvhZcShtpqD0y5KGzc1c6I$ ), [2012](https://urldefense.us/v3/__http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2012/thread.html__;!!G2kpM7uM-TzIFchu!gLR5wmXEkR9EbaC2aF5t_00SHATOFr3MoE9rj6HVAJPUrdvl_Kv0xkvhZcShtpqD0y5KYXIIkf0$ ), and [2013](https://urldefense.us/v3/__http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/thread.html__;!!G2kpM7uM-TzIFchu!gLR5wmXEkR9EbaC2aF5t_00SHATOFr3MoE9rj6HVAJPUrdvl_Kv0xkvhZcShtpqD0y5KSvyqLa8$ ) (e.g. https://urldefense.us/v3/__http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/006106.html__;!!G2kpM7uM-TzIFchu!gLR5wmXEkR9EbaC2aF5t_00SHATOFr3MoE9rj6HVAJPUrdvl_Kv0xkvhZcShtpqD0y5KkbbkA8k$ , https://cf-trac.llnl.gov/trac/ticket/74) - which is well worth revisiting if you have the time. Here are my initial thoughts on the detailed proposal: #### Standard names I don't that these standard names will work, for two reasons: 1. they do not describe what the quantity stored by the ancillary variable _is_, rather they describe its _role_ . For example, if variable contains the standard deviation of air temperature, then its standard name and cell methods should say so. How that quantity is to be interpreted by the parent data variable should be stored be stored elsewhere. I'm reminded of the `cf_role` attribute, here, as used by [DSGs](https://urldefense.us/v3/__https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html*coordinates-metadata__;Iw!!G2kpM7uM-TzIFchu!gLR5wmXEkR9EbaC2aF5t_00SHATOFr3MoE9rj6HVAJPUrdvl_Kv0xkvhZcShtpqD0y5Kufg68ac$ ). 2. it is not possible for them to have canonical units, which all standard names must have. >From reading the [GUM] reference you very helpfully provided in the >bibliography >(https://urldefense.us/v3/__https://www.bipm.org/utils/common/documents/jcgm/JCGM_100_2008_E.pdf__;!!G2kpM7uM-TzIFchu!gLR5wmXEkR9EbaC2aF5t_00SHATOFr3MoE9rj6HVAJPUrdvl_Kv0xkvhZcShtpqD0y5K6f6d8SY$ > ), I'm a bit confused on the definition of "total_uncertainty". Your >reference to "the square root of the sum of squares" might suggest that it is >the [GUM]'s "standard uncertainty" - is that right? I felt the prefix `specific_` was a bit misleading. Perhaps `component_` might be clearer? #### Cell methods It would be very useful to include the parent data variable in the examples that have ancillary data cell methods. Without that reference I can't fully understand what the `name:` of the cell method is referring to - is it a standard name, or a dimension of the parent data variable? It's worth reviewing Jonathan Gregory's ["measurement" dimension idea](https://cf-trac.llnl.gov/trac/ticket/74#comment:40) in this light (but I've not followed that train of thought through myself, yet). I'm not sure that `other_than_statistical_analysis` is a cell `method`. The [GUM] says that , Type B uncertainties are characterised in the same way as Type A ones (e.g. by standard deviations), but it is only _how_ the uncertainty was arrived at that is different: Type A is obtained from an observed frequency distribution; Type B comes from an assumed probability density function. In the Type B case, there are perhaps further complications, if one considers the stored values to not be representative of sub-grid variation. There is already a `standard_error_multiplier` attribute that states the multiplication factor for the standard error. Including a `standard_deviation_multiplier` (for example) would seem the way to go rather than using the cell method comment section. I'm confused how the confidence interval in example 10.4 is stored as a scalar. Is it in fact half of an interval that is symmetric about the measurement? If so, the `method` should perhaps reflect this. #### Ancillary variables Allowing cell methods to be interpreted on ancillary variables could be allowed, provided that the the cell method names could also be plausibly applied to the data variable - see comments above on the interpretation of the cell method names. Ancillary methods containing ancillary methods and having trailing dimensions - these need more thought, and I'll post again when I've had time to do so. All the best, David -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/320*issuecomment-843029547__;Iw!!G2kpM7uM-TzIFchu!gLR5wmXEkR9EbaC2aF5t_00SHATOFr3MoE9rj6HVAJPUrdvl_Kv0xkvhZcShtpqD0y5KP6nmnTM$ This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
