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.hetl...@sintef.no> ----- > From: Ben Hetland <ben.a.hetl...@sintef.no> > To: "cf-metadata@cgd.ucar.edu" <cf-metadata@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 deci de > 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@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
