Re: [thredds] Metadata_Conventions VS Conventions attributes

Hi Nathan, all,

Nathan Potter wrote:
> 
> Following a fairly long discussion about identifying metadata
> conventions (1st message here:
> http://www.unidata.ucar.edu/mailing_lists/archives/thredds/2010/msg00008.html
> ) we arrived at a road block due to differences in the way three
> documents describe the mechanism through which one would identify
> the list of metadata conventions used in the data:

This discussion has been brought up on the cf-metadata list. Here's a
good summary of the current CF activity on this front:

On the cf-metadata list, Jonathan Gregory wrote
> Both of your discussions are somewhat related to CF trac ticket 27
> https://cf-pcmdi.llnl.gov/trac/ticket/27
> 
> In the latter part of that, there is generally agreement that we should allow
> other conventions to provide attributes which are labelled with a prefix, as
> Heiko suggests for including a discovery metadata convention. There seems to 
> be
> no problem with that, so long as the other convention is not providing the 
> same
> kind of metadata as CF, so there will not be any contradiction.
> 
> There has been other discussion recently on this email list concerning the
> issue of naming other conventions in the Conventions attribute. I don't think
> the original intention was to exclude that possibility. It's just not
> recognised in the CF standard and it should be. However, no-one's had time
> propose an amendment. Personally, I think it's OK so long as the extra
> conventions accept all of CF, and just add more conventions which do not
> conflict. If they overlap, this has to be thought about carefully, and in that
> case I would say that the CF standard would have to be amended to describe how
> the overlaps should be resolved.

I'll spend some time working on CF trac ticket 27 and hopefully get that
moving forward. With all this recent interest, I'm guessing we'll have
some movement on rewording the "Conventions" attribute section as well.

I will also take a look at the "NetCDF Attribute Convention for Dataset
Discovery" document with an eye towards modifying, backwards
compatibility, and any changes to CF.

--
Ethan

Nathan Potter wrote:
> 
> 
> Greetings,
> 
> Following a fairly long discussion about identifying metadata
> conventions (1st message
> here: 
> http://www.unidata.ucar.edu/mailing_lists/archives/thredds/2010/msg00008.html
> ) we arrived at a road block due to differences in the way three
> documents describe the mechanism through which one would identify the
> list of metadata conventions used in the data:
> 
> 
> NetCDF Conventions:
> http://www.unidata.ucar.edu/software/netcdf/conventions.html
> 
> CF-1.4:
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#identification-of-conventions
>  
> 
> NetCDF Dataset Discovery:
> http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
> 
> 
> 
> The problem:
> 
> The NetCDF COnventions page identifies an attribute called
> *Conventions* to be used to provide a list (space or comma separated) of
> one or more metadata conventions used in the file. In the CF-1.4 page,
> section 2.6.1 Identification of Conventions provides a description of
> the use of the *Conventions* attribute that can easily be (mistakenly)
> interpreted to mean that the *Conventions* attribute may not contain a
> list. In the NetCDF Dataset Discovery page the *Conventions *attribute
> is replaced by a *Metadata_Conventions *attribute that appears to be
> synonymous with the previously defined *Conventions* attribute.
> 
> 
> A solution:
> 
> 1) Clarify the CF-1.4 page so that it is explicitly clear that a space
> or comma separated list of conventions is allowed.
> 
> 2) Amend the NetCDF Dataset Discovery draft so that it
> uses* Conventions. *Either by replacing *Metadata_Conventions *with
> *Conventions*, or by explicitly stating that *Metadata_Conventions* and
> *Conventions* are synonyms (semantically identical)
> 
> Can you guys get together and make that happen? Am I asking a lot?
> 
> 
> Nathan