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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20111121/b6f5577f/attachment-0001.html>
Received on Mon Nov 21 2011 - 11:38:26 GMT
