Hmmm, this quickly gets to be the kind of discussion where different
readers takes away different meanings, depending on their initial
prejudices. What are the semantics of "semantics" and "conventions"
(*)? If our interpretation of these words is that "semantics" refers to
*meanings* of language, whereas "conventions" refers to the particular
*words and syntax* chosen to express those meanings, then I think we'd
want to edit John's bullets to be something like:
CF may incorporate an outside convention into it when the following
conditions hold:
1. CF is already capable of expressing the underlying coordinate
systems and relationships between variables that are proposed
for introduction from the outside convention.
2. The convention is already in wide use by other communities, and
the adoption by CF significantly helps other communities adopt
CF and thereby advances interoperabilty.
3. The convention does not introduce significant ambiguities in the
interpretation of a CF dataset.
4. Since (by #1) the new conventions necessarily overlap existing
CF conventions, /software should be developed/ to detect
inconsistencies and provide feedback to the data producer.
What about the "software should be developed" phrase in #4? To have
teeth, it would need to say
4. Since (by #1) the new conventions necessarily overlap existing CF
conventions, /software must be provided/ that detects
inconsistencies and provides feedback to the data producer before
the outside conventions will be adopted.
- Steve
* If "semantics" is "_*how*_ words (or computer syntax-es) are assigned
meanings", then it refers to both the words and the meaning ... which is
why it is ambiguous in this context.
** I've pasted John's original text here for comparison:
/*Original:*
"CF may incorporate an outside convention into it when the following
conditions hold:/
1. /The semantics of the convention are important to the CF community./
2. /The convention is already in wide use by other communities, and
the adoption by CF significantly helps other communities adopt CF./
3. /The convention is not in conflict with existing CF standards./
4. /In the case that the new convention overlaps existing CF
conventions, software should be developed to detect
inconsistencies and provide feedback to the data producer./
------------------------------------------------------------------------
On 11/21/2011 9:49 AM, Jonathan Gregory wrote:
Dear John
I agree with these principles. I think we might phrase 3 and 4 as balanced
alternatives:
"CF may incorporate an outside convention into it when the following
conditions hold:
1. The semantics of the convention are important to the CF community.
2. The convention is already in wide use by other communities, and the
adoption by CF significantly helps other communities adopt CF.
3a. Either, the convention does not overlap existing CF conventions
3b. Or, if it does overlap existing CF conventions,
software is provided to detect inconsistencies
and provide feedback to the data producer.
and we could append "or data user" to that. The producer might not have
checked, and the user needs to be warned. I changed "should be developed"
to "is provided", since it's a condition for incorporating the convention.
It's important that your proposal says "may". We don't *have* to do this.
It depends on whether it's a good solution to a need.
CF doesn't currently have a statement of principles, though. Such a statement
could be put into the Goals section at the start, I suppose. Here is another
list, which comes from the CLIVAR article of some years ago, that's linked
from the CF home page
http://cf-pcmdi.llnl.gov/documents/other/cf_overview_article.pdf
I would propose these for inclusion as well:
The general principles in the design of CF are as follows. (1) Data should be
self-describing. No external tables are needed to interpret the file. For
instance, CF doesn't use numeric codes, like GRIB does. (2)
Conventions have been developed only for things we know we need. Instead of
trying to foresee the future, we have added features as required and will
continue to do this. (3) We wish to avoid being too onerous for data-writers
and users of data, as this will make the standard unattractive. (4) The
metadata should be readable by humans as well as easily parsed by
programs. (5) Redundancy is minimised---a good general principle because it
reduces the chance of inconsistency---and we try also to limit
possibilities for making mistakes when writing data.
Cheers
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
