⇐ ⇒

[CF-metadata] "positive" attribute

From: John Caron <caron>
Date: Thu, 28 Jun 2007 10:35:14 -0600

How about:

CF 1.1 : evolution, backwards compatible
CF 2.0 : revolution, "do-over".

Bryan Lawrence wrote:
> Ok. That's clear then. Decision accepted from my point of view
> (Jonathan+Roy>>Bryan :-)
>
> However, it does bring up a different issue. Should we be collecting a list of
> issues somewhere that should feed into the revolution if/when it happens?
>
> Cheers
> Bryan
>
>
> On Thursday 28 June 2007 16:42:10 Roy Lowry wrote:
>> Hi Bryan,
>>
>> I would prefer any changes in Standard Names conventions/practices to be by
>> revolution rather than evolution, even if that evolution is from bad to
>> good practice. Semantic modelling and ontology creation are much easier if
>> there are consistent patterns in the base lists. So, I agree with Jonathan
>> even if my reasons are somewhat different.
>>
>> Cheers, Roy.
>>
>>>>> Bryan Lawrence <b.n.lawrence at rl.ac.uk> 6/28/2007 4:30 pm >>>
>>> data would not be self- describing. Not knowing the sign convention is a
>>> serious problem for analysis of data. The fact that the data would not be
>>> CF-compliant would be no consolation for its being useless. It is better
>>> to prevent problems happening.
>> (Possible response: Make the sign mandatory. I think asking someone who
>> didn't read the CF convention when they designed their model to rerun the
>> model or rewrite the output is a bigger ask than adding one tiny attribute
>> to each variable ... and one which which would make software deciding what
>> to do with comparing data much easier to design).
>>
>>>> What happens if I build (or have) a model which happens to have a
>>>> different sign convention than the one chosen thus far? Do I have to
>>>> reprocess all my data, or introduce a duplicate set of standard names
>>>> with the opposite convention embedded. The latter doesn't seem right!
>>> You have to introduce other standard names. We already have several
>>> upward/ downward pairs for this reason, but it turns out that in practice
>>> there is not lot of such duplication, because people tend to use common
>>> conventions, so it's never been suggested to present a significant
>>> problem. Hence I think the evidence is that this pragmatic decision was
>>> reasonable, and although other decisions could have been taken there is
>>> at present no reason to change the guidelines.
>> That's an argument for inertia, which is certainly pragmatic, but I think
>> there are things coming for which this is not going to be so easy. What
>> about family chemistry? I bet there is no convention on the deltas between
>> families? What about different soil/ice/river/hydrology models? I know one
>> of our guiding principles is not to worry about the future too much, but a
>> little thought for *very* little overhead would help significantly in the
>> future. I think Forrest's first email was on the button, our primary
>> assumption is that things have a default (up/down) orientation will be much
>> harder to sustain in the muddy world (pun intended) of earth system models,
>> and having two standard names is just more work than is necessary ...
>>
>> What I'm suggesting is that the guidelines for new "groups" of standard
>> names could be different from those in the past. I'm also suggesting
>> something that will make the business of *maintaining* lists (and soon,
>> ontologies, easier).
>>
>> But having said all this, I dont feel so strongly about it that I intend to
>> say any more on this, unless someone else feels strongly enough to force a
>> vote ... :-)
>>
>> Cheers
>> Bryan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Jun 28 2007 - 10:35:14 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒