Hi Jonathan,
> 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.
Section "5.2 Guiding Principles" of the NASA ESDS Community Standard
document for CF Metadata Conventions
http://www.esdswg.org/spg/rfc/esds-rfc-021/ESDS-RFC-021-v0.01.pdf
also lists those five principles (reworded) as well as a few more
specific guidelines, including
- Limited redundancy is tolerated if it supports the independence of
variables from each other, so that extraction, copying, and merging
of separate variables is more practical.
--Russ
Received on Mon Nov 21 2011 - 12:31:14 GMT
