Hi Nan,
A bit hurried response here, but it is an important topic that was
dropped following Derrick's email 7/14/2009 (Subj: "Conventions vs.
Community Profiles")
As an answer to your immediate question -- my 2 cents:
1. It would be best not to "break" the CF conventions, so retaining
simply the unadorned Conventions = "CF-1.4" seems the best choice.
2. You can pick any non-reserved attribute name that you want to
enable the OceanSites-specific software to detect the additional
conventions. There is a danger of future attribute name
collisions, and your specific community's software, alone, (I
assume?) has an interest in this attribute. So I'd suggest that
the attribute name you pick is quite specific to your needs. e.g.
* OceanSitesConventionsVersion = 1.0;
====
For the larger CF community we should consider whether there is value in
having a general sub-conventions attribute of the style that Derrick
proposed. His proposal was
.Profile = "XBT-1.0" or .Community_Profile or whatever?
If the growth of CF continues as we expect, then these issues are going
to be arising more often. In the end the extended family of CF datasets
will be cleaner and more intelligible if there is an identified
attribute that can be examined to identify what sub-conventions
(profile) were followed. To make such an attribute mandatory would
break a lot of existing files. But the attribute does seem worthy to be
stated as a "recommended attribute" in CF documentation.
Should we open a trac ticket?
- Steve
==================================
Nan Galbraith wrote:
> Hello all -
>
> Although we have not had any more input on the best way to
> declare a community profile in a CF-compliant file, I still have a
> question. I think this also relates to the namespace ticket (#27)
> on the trac system.
>
> The trac ticket mentions that using comma-separated conventions is the
> method suggested in the NetCDF documentation, although the page
> referenced,
> http://www.unidata.ucar.edu/software/netcdf/guidef/guidef-13.html,
> is not a working link.
>
> The CF compliance checker chokes on a compound conventions
> attribute, like Conventions = "CF-1.4, OceanSITES-1.0" - is this the
> accepted
> method of declaring multiple conventions, or do I need to stick with
> a pristine "CF-1.4" and declare the OceanSITES compliance in a separate
> attribute, perhaps, as Derrick suggested, using a "profile" attribute?
>
> Since most of the OceanSITES participants are now generating data in
> this format, and since we are requesting that they check their files for
> CF compliance, I'd really like to know the preferred way to do this.
>
> Again, the OceanSITES spec is completely CF compliant, it just imposes
> more restrictions, essentially simplifying CF for use with in situ
> data (although,
> IMHO, it's probably quite a bit more rigid than is really necessary).
> Thanks -
> Nan
>
>
> John Caron wrote:
>> Derrick Snowden wrote:
>>> ... My question is, how does one go about developing a community
>>> profile? Does this end up being another convention or is it
>>> distinct in its representation in the file. For example, would the
>>> global attributes look like
>>>
>>> .Conventions = "CF-1.4, XBT-1.0" or
>>>
>>> .Conventions = "CF-1.4"
>>> .Profile = "XBT-1.0" or .Community_Profile or whatever?
>>>
>>> Clearly anything can be done, my question is does anyone care to
>>> comment on what should be done? I know other communities such as
>>> Argo and OceanSITES have made some choices but I'm not sure if
>>> they're the right ones.
>>>
>> Hi Derrick:
>>
>> ...
>>
>> The CF Conventions try to constrain the storage choices to a
>> reasonable balance between efficiency for the writers and
>> interoperability for the readers. We havent seen too much profiling
>> within it, and the less the better. However, as the CF specification
>> grows and covers more types of data, no doubt we will see some of this.
>>
>> With regard to
>>
>> Conventions = "CF-1.4, XBT-1.0"
>>
>> I'd ask, what semantics does "XBT-1.0" imply that "CF-1.4" doesnt ?
>> Because something not in CF means that its not interoperable with CF
>> clients.
>>
>> We are doing something like this for OceanSITES, and yes, the
>> extra information in the Conventions attribute is important to us.
>>
>> The files are CF compliant, so 'CF-1.4' in this attribute tells the
>> user he can use any code that reads CF to read them. The
>> 'OceanSITES 1.1' in the attribute tells the user about some additional
>> restrictions and assumptions he can make.
>>
>> For better or worse, we hard-wire some features (e.g. reference date),
>> and add some restrictions (e.g. units) , in order to simplify the
>> code that
>> reads these files. This makes NetCDF a little less daunting for people
>> who haven't used it before, or who might find its flexibility a problem
>> rather than a feature.
>>
>> - Nan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20090901/ab2d0586/attachment-0002.html>
Received on Tue Sep 01 2009 - 10:28:01 BST
