Hi Jonathan, Thanks for the reply. You have proposed some good ideas to ponder.
I like your idea to use _statistical_ and _subjective_ for the Type A and Type B terms. I'll incorporate that suggestion. I understand the argument against using _stanard_name_ because of the conocial units issue. If that is a deal breaker we can find another method. I will need to think about the _cell_methods_ suggestions some more. But I can say I'm not excited about that option. I've been pushing the use of _cell_methods_ with my institution and it's not being accepted well. It is often quite difficult to encapsulate a description of the process into the cell_methods attribute, and most of my colleagues don't want to add that attribute. I spend a lot of time ensuring other critical attributes make it into the datasets, so I've been pushing less hard lately. I also see this as a slippery slope. If cell methods becomes required (in this case it is THE metadata to indicate uncertainty) then we should require it for other metadata variables. I'd prefer to require a less complicated way to indicate a type of data value. I agree we should not add new attributes if an existing attribute already exists. My main concern is to find a method that is simple to write and simple to understand for our data users. Most of our data products have different types of methods of uncertainty and I need to find a solution that work for all of them. Most data users will not care how the uncertainty value was derived, only that the institution which created the data file are providing their best guess uncertainty estimation. They will then use that uncertainty estimation in their work. Often the uncertainty value provided will not be of the form most desireable to their research, but if that is all the researcher is provided they will find a way to use it. Therefore, I'm trying to not require the uncertainty to be defined by the details of the method used to derive the uncertainty. Thanks, Ken -- 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-901401748__;Iw!!G2kpM7uM-TzIFchu!mq6qRHlCgqy4Eu7Ih6WTnbIYb70F8miWYMd-WJZBn6hanbS5Sxgp-QMsskqdFcyMaxVjl7aPbYA$ 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].
