Question about Appendix C: Standard Name Modifiers

[EDescourvieres]

Question

Dear all,

I would like to ask a few questions regarding “Appendix C: Standard Name Modifiers“ (https://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#standard-name-modifiers).

There are currently four modifiers (“detection_minimum,” “number_of_observations,” “standard_error,” and “status_flag”). Would it be possible to include additional modifiers, such as “bias,” “standard_deviation,” “uncertainty,” or “anomaly”?

In section 3.3 Standard Name, it is written “A standard name is associated with a variable via the attribute standard_name, which takes a string value comprised of a standard name optionally followed by one or more blanks and a standard name modifier (a string value from Appendix C, Standard Name Modifiers).” Consequently, if I understand correctly, the standard name compliant with CF “sea_ice_area_fraction” is also compliant when written as sea_ice_area_fraction standard_error and sea_ice_area_fraction_standard_error, is that correct ?

Thank you in advance for your help,

Best regards,

Emmanuelle Descourvières

[EDescourvieres]

Dear @eileenhertwig-dkrz and @JonathanGregory ,
I am writing to ask whether, in your opinion, I have posted my question in the appropriate section. If I have made a mistake, I would be grateful if you could let me know and advise me on the correct section in which to post my question.
Thank you in advance for your help,
Best regards,
Emmanuelle Descourvières

[sadielbartholomew]

Hi Emmanuelle,

I will try to respond (including to the second sub-question even though not directed at me, because the answer is a quick one!), but encourage anyone else to comment to clarify or certainly to correct me if I say anything incorrect!

am writing to ask whether, in your opinion, I have posted my question in the appropriate section

Yes, this is the most appropriate place to pose a CF question of this nature or more generally any question, as covered by the discussion page of the website which you may have seen - though it wouldn't be wrong to alternatively post via a new Issue in the Issues Tracker of the conventions repo, or even the vocabularies repo since this concerns standard names.

If you are concerned because you haven't yet received a reply yet, I would note that sometimes it can take some weeks for replies because people are busy - in particular this can be the case approaching a new release of CF or the standard names table etc. Though it depends on who knows how to answer the question and when they read the thread.

Consequently, if I understand correctly, the standard name compliant with CF “sea_ice_area_fraction” is also compliant when written as sea_ice_area_fraction standard_error and sea_ice_area_fraction_standard_error, is that correct ?

Yes, that is how it works for valid modifiers, though it must be a space not an underscore - if you see https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#standard-name it clarifies 'standard name optionally followed by one or more blanks and a standard name modifier' must be used (emphasis my own).

Would it be possible to include additional modifiers, such as “bias,” “standard_deviation,” “uncertainty,” or “anomaly”?

New additional modifiers could certainly be proposed, but in the case of all but one of those you suggest - “standard_deviation,” “uncertainty,” or “anomaly” - these aren't good candidates for modifiers. I'll try to break this down to explain:

• 'anomaly': anomalies have been discussed extensively within the community recently resulting in the introduction of a generalized framework for anomaly data (Section 7.5, "Anomaly Data"): https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#anomalies in CF 1.13. It provides a standard way to describe anomaly variables and the norms from which they are derived.
• 'standard_deviation' and 'uncertainty': are both uncertainty related, and while nothing has yet been written up that I can link you to on GitHub, I am aware there are a group within the CF community who are preparing work to formalise the description of uncertainty in CF, which would allow encoding of both these terms in a standard way that is much more flexible way that through the use of a modifier. But until that has been formally proposed, discussed and eventually perhaps incorporated into CF, there are other ways to clarify uncertainties - I just need to ask about what the best way is for now. I'll try to respond further about this, but in the meantime if anyone reads this and knows more please do jump in to summarise!

Bias, however, might be a good candidate for a new modifier, since I am not aware of any specific framework or guidance for handling biases - though the uncertainty work above may include bias handling (I am not sure but it is possible).

Best wishes,

Sadie

[sethmcg]

I don't think bias would work as a modifier, because you need some way to specify what the bias is relative to. I think actually it sounds like a logical extension of the recently-developed anomaly framework.

Do you know who's on the uncertainty team? It would be good to ping somebody and make sure they're thinking about the relationships between anomalies, biases, and uncertainty, since we want whatever frameworks we end up with for them to all play nicely together.

[sadielbartholomew]

Ah I see, fair enough! Biases are certainly not my topic of expertise so thanks for clarifying.

Do you know who's on the uncertainty team?

Yes, please get in touch with @davidhassell about uncertainty work.

[JonathanGregory]

Dear Emmanuelle

Thanks for your questions, and well as for your engagement with and many contributions to CF standard names. As @sadielbartholomew says, this is the right place to ask, but sometimes answers don't come quickly because CF is all "voluntary" effort.

I agree with @sadielbartholomew's and @sethmcg's comments. We have newly introduced conventions for anomalies; bias might be related to anomalies; uncertainty and perhaps standard deviation may be related to the uncertainties project, which @davidhassell is coordinating. Please could you say a bit more about your intended uses of standard deviation, uncertainty and bias? You might also be interested in this somewhat related recent question from @Roebeling.

Best wishes

Jonathan

[davidhassell]

Hi @EDescourvieres,

We do indeed have a complete proposal on uncertainty [*] that is currently being beta-tested and will be proposed formally to CF soon (certainly before the CF workshop in September, where we aim to have some sort of presentation of the ideas and implementation). I'll give a few ideas from it that relate to the discussion points raised ...

This proposal deprecates the use of the standard_error standard name modifier on an ancillary variable as a means of expressing uncertainty in the data variable, because for that purpose it is unfortunately poorly constrained and poorly defined.

The main idea is that new "uncertainty variables" (named by the data variable uncertainty_variables attribute) are introduced which act as containers for all sorts of uncertainty metadata - ranging from the very simple "this is the standard uncertainty" to the much more complicated "detailed description of the nature of the sampling distribution and error correlations along subsets of data axes".

Any number of uncertainty variables can be provided, each of which is a component of the uncertainty, and the combined uncertainty itself may also be given. Each component is self-describing (you can describe the nature of the component), and these components can (under certain conditions) also be combined by the user

Uncertainty associated with an anomaly can be provided in this way - it is just another component of the combined uncertainty of the data variable.

There is no formal treatment of bias in the proposed uncertainty treatment, because a systematic error is not itself a component of uncertainty, and when estimated as a bias it is ideally corrected for in the data values prior to the calculation of the uncertainty interval. If the data remains uncorrected, a known bias should be accounted for by the uncertainty interval, which may result in uncertainty intervals that are asymmetric relative to the data, and which might not contain the data values (both cases that are also catered for by the uncertainty proposal). Note that there can be an uncertainty associated with the magnitude of the bias itself, which should either be incorporated into the calculation of the combined uncertainty interval, or provided in its own uncertainty variable.

If you wanted to store the bias inside the dataset, I would think that would be an ancillary variable with a long_name that described it as the bias of the original data, and perhaps the long_name of the data variable would state whether or not it was bias corrected - but I'm sure there are other ways to do that, too.

[*] Co-authored by myself, Owen Embury, Sam Hunt, and Pieter de Vis

[larsbarring]

Just out of curiosity: what "types" of uncertainty are you aiming to cover?

[davidhassell]

Hi Lars,

The framework is generic, so you should be able to store whatever you like ... if by type you mean "Type A/B", then there is an attribute specifically for that (although we don't use that vocabulary!). It's about time we got the issue and PR up, then everyone can see what we're proposing ....

[larsbarring]

Hi David,
With "Type A/B" I guess that you are referring to statistical significance/power in context of classical statistical testing and confidence intervals, which of course is highly relevant. But I was thinking in more general terms, like: observational uncertainty (instrument/observer errors, site representativity, ...), model [ensemble] limitations/uncertainty (spatial/temporal resolution, limitations in physical parametrisations, [un-]representation of processes), scenario/pathway uncertainty and all what comes with that. And so forth...

For some reason I came to think of TOBLER'S FIRST LAW: Everything is related to everything else, but near things are more related than others.

[davidhassell]

Hi Lars - I see! The what we're proposing is an ability to store "GUM" uncertainty (https://doi.org/10.59161/JCGM100-2008E), which says (I paraphrase) uncertainty of a measurement is a measure of the dispersion of the values that could reasonably be attributed to the measurand, and that dispersion is represented as a coverage interval that contains the true value of the measurand with a given probability. This definition of uncertainty should be relevant to any application, and if not we may need to do something about it!

Here's a snippet from the text (the issue and PR will be up soon!):

---

Measurement, in the context of uncertainty, is the process of obtaining a numerical value that represents a physical quantity (i.e. the measurand). A measured value is typically derived from a numerical simulation (e.g. climate model output), a direct observation (e.g. sensor data), or a remote sensing platform (e.g. satellite retrievals). The error of a measurement is the measured value minus the true, unknowable value of the measurand. The uncertainty of a measurement is a measure of the dispersion of the values that could reasonably be attributed to the measurand.

Uncertainty of a measured value is expressed as a statistical coverage interval (hereafter referred to as a “coverage interval”) that contains the true value of the measurand with a given probability, i.e. the range of values within which the true value is expected to lie. A coverage interval is derived from the probability distribution of the measurand (hereafter referred to as the “probability distribution”), which is evaluated by an analysis of a sample of measurements, by scientific judgement, or by a combination of these methods. For instance, for a measured value of 50 there could be a probability of 0.95 that the true value lies within the coverage interval [40, 60]. This concept is applicable to any probability distribution, including Gaussian, non-Gaussian, and asymmetric distributions. For example, when a coverage interval is defined for a skewed probability distribution, the interval limits would typically be asymmetric about the measured value.

[EDescourvieres]

Dears,

Thank you all for your complete and detailed responses.

If I understand correctly:

• It is possible to use a standard name preceded by a modifier, for example: “sea_ice_area_fraction standard_error”.
• For “anomaly”, I should refer to https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#anomalies.
• For “bias”, this is a logical extension of the framework recently developed for anomalies, so the corresponding reference should be made to that framework.
• For “uncertainty”, a complete proposal is currently being tested and will soon be officially submitted. (“standard_deviation” is related to uncertainty.) Could you please keep us updated on the progress of this proposal?

Please let me know if I have misunderstood any of the points above.

Thank you again for your help,

Best regards,

Emmanuelle Descourvières

@abiardeau , @RosmerySosaG

[feggleton]

@japamment - flagging so you can pass comment