Dear Ben
Your arguments are reasonable and I have no answer except to say that there
are many possible choices, and we are following a compromise that has
apparently worked well for a number of years. It has been suggested before
that CF itself should be more prescriptive about what quantities are allowed
in CF datasets, I think, but that hasn't been a popular idea. Instead, we
have agreed names for quantities people want to describe with CF. Just as
netCDF is a general framework within which CF is a convention used for
certain purposes, more specific purposes (such as CMIP) develop their own
conventions to impose further constraints on how CF is used in their dataset.
Best wishes
Jonathan
----- Forwarded message from Ben Hetland <Ben.A.Hetland at sintef.no> -----
> From: Ben Hetland <Ben.A.Hetland at sintef.no>
> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Date: Fri, 12 Sep 2014 19:15:27 +0000
> Subject: Re: [CF-metadata] downward_air_velocity
>
> Dear Richard and others,
>
> > If we tried to be prescriptive, it might either (a) prevent
> > people from using CF, or (b) using it incorrectly, because it
> > didn't quite fit their needs, but they didn't want to change
> > how they did things.
>
> or (c) using it incorrectly because they didn't quite understand
> all the requirements to be compliant with the standard.
>
> Those are all fair arguments, indeed, and valid concerns. I observe that there is nevertheless a delicate balance to decide on which side of the "acceptance threshold" each such requested feature falls. For instance I noticed that you just "rejected" the idea of introducing an attribute for positive direction, due to concerns matching (b) or possibly (c). Good! However, my view is that multiple names for the same kind of data just falls into the very same category. As the names serve a certain semantic purpose within CF, defining several identifiers for the same opens up for another set of potential problems. What if some person at some point interprets this to mean that they should write _both_ variants, for instance? How should the reader interpret that situation, and would it imply that they should bother to actually check that the two sets are consistent? Or what about some reader software being (stupidly) hardcoded to look for "downward_foo", but the data provider decide
> d at some point that it was more convenient to use "upward_foo"? That would be a show-stopper for using CF for the poor user that is using those two pieces of software... or at least an annoyance for a while!
>
> I agree to the concern about people being prevented from using CF. However, if someone decides to go with -say- CF, they probably do so for the benefit they think they will get from that. If the "price" is high for them to adapt "how they did things", then surely they would consider something else. However, all of the features discussed in this thread are almost trivial to adapt to, so for most people these are not a cause for concern of type (a).
>
>
> > However, in practice most projects which generate CF data
> > (like CMIP) have their own further conventions, which usually
> > do prescribe more precisely what should be stored, in terms
> > of standard names.
>
> That might be so for many projects, but if they have prescribed CF and CF says "downward_foo" it is, would it stop them from using that even if they internally keep values with upward positive direction?
>
>
> > So for any particular project your preference above is met,
> > but it may differ from project to project.
>
> Does this assume that the "project" would incorporate both the data generator part, as well as the consumer of those data?
>
> In most of "my" projects, I never get to choose the variable names at all! They might have been produced long ago, or I don't have an influence on how they are produced. I am then faced with interpreting what the "user" decides to feed into my software in the best possible way, which also means I might have to cope with every possibility the "standard" allows (and then some for good measure). This is generally why I advocate keeping the standard as minimal and unambigious as possible given that it also must cater to everybody's needs (like Occam's Razor).
>
> --
> Best regards,
>
> -+-Ben-+-
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Mon Sep 15 2014 - 10:26:59 BST
