Hmmm, I GUESS it's good that someone noticed that text, and
I'm surprised how much on that page I miss every time I look at
it.  I'm not sure what the advantage is in inserting the '/'  vs using
a space, and I'm very curious if any existing software recognizes
that syntax.

It seems to me that the authors intended the '/' to be used
for specifications that are "tweaked" versions of major standards;
SeaDataNet is a full-blown standard, though, and IMHO should
be listed as a separate entity (blank separated) in this space.

What happens to data that is compliant with both SeaDataNet and
(e.g.) OceanSITES?  It's not a problem if these are each listed separately.

And, regarding the care we need for using multiple conventions, it seems
logical that the authors of standards like SDN, OceanSITES and ACDD
would be responsible for ensuring that their specifications don't conflict
with CF. This is why it's critical for the developers to provide an open venue
for users to discuss the details of a new standard.  CF certainly provides
this kind of forum, so if we're adding a term, we can be fairly sure that
users of other standards have the opportunity to comment on possible
conflicts.

Cheers - Nan


On 12/29/11 10:14 AM, Lowry, Roy K. wrote:
Thanks Mark,

It's good to have somebody reading stuff that I should read but never have the 
time! That certainly works for me. Providing there are no comments to the 
contrary that would make ''CF-1.6/SeaDataNet' or maybe 'CF-1.6/SeaDataNet-1.0' 
the value to be specified in the conventions attribute for the SeaDataNet 
NetCDF profile that will be a part of SeaDataNet II.

I feel it is essential for profile documentation to be published if data 
conforming to that profile are to be made publicly available.  Further, if the 
data are to be exposed through INSPIRE then the way in which the profile is 
documented should follow the ISO conventions (it's one of the ISO19xxx 
documents, but I forget which).

Cheers, Roy.
________________________________________
From: [email protected] [[email protected]] On 
Behalf Of Hedley, Mark [[email protected]]
Sent: 29 December 2011 13:27
To: [email protected]
Subject: Re: [CF-metadata] Convention attribute

hello Roy

I wonder if this could be captured by the notation in the Unidata documentation:

'''
Later, if another group agrees upon some additional conventions for a specific subset of 
XXX data, for example time series data, the description of the additional conventions 
might be associated with the name "XXX/Time_series", and files that adhered to 
these additional conventions would use the global attribute

     :Conventions = "XXX/Time_series" ;
'''
(http://www.unidata.ucar.edu/software/netcdf/conventions.html)


Does this provide a mechanism for profiling CF?:

:Conventions = "CF-1.6/mark'sFruityProfile"

Does the profile name "mark'sFruityProfile" get recorded somewhere?

Should this be published, or can I keep it to myself and my friends?

By the nature of the :Conventions declaration I have stated that 
"mark'sFruityProfile" is CF compliant, is that enough information?

cheers
mark

-----Original Message-----
From: [email protected] on behalf of Lowry, Roy K.
Sent: Thu 29/12/2011 10:08
To: Jonathan Gregory; [email protected]
Subject: Re: [CF-metadata] Convention attribute

Dear All,

One thought that this debate has brought to mind is what should the practice be 
if the file convention is a profile (in the ISO sense) of CF?  In other words, 
the file conforms to a given version of CF modified by a formally documented 
set of extensions (e.g. optional CF attributes declared as mandatory or 
additional attributes in the profile's namespace).  Should both the CF 
convention and the profile name be included?  My vote would be yes to avoid 
application software having to be aware of all CF profiles, but should there be 
any indication that it is a profile rather than an independent parallel 
standard?

Cheers, Roy.

________________________________________
From: [email protected] [[email protected]] On 
Behalf Of Jonathan Gregory [[email protected]]
Sent: 28 December 2011 22:22
To: [email protected]
Subject: Re: [CF-metadata] Convention attribute

Dear Mark and Dave

I agree with Dave's answers. If two conventions are used together, it is the
responsibility of the data-writer to guarantee that the metadata supplied is
consistent if there are any overlaps in meaning. A particular case of that is
if the two conventions define attributes with the same names. It has been
suggested that conventions could signal their own name-spaces e.g. CF
attributes could all be prefixed with "cf_" (like the cf_role attribute, which
has been introduced in the new CF section 9). That could help with preventing
collisions of namespaces, but

* it would be cumbersome for writers of files that adhere to only one
convention, which is the usual case, and awkward for programs that read files,
since they would have to check for every attribute by two different names
(with and without the prefix, considering all the data that already exists
without prefixes).

* it doesn't help if the two conventions are inconsistent in their metadata,
whether or not they use similarly named attributes, and this is the more
serious problem, I would argue.

Therefore I don't think this is really a magic solution to get rid of the
potential difficulty. Rather, the writers of conventions have to be aware of
other netCDF conventions that might be used with theirs, and try to use ones
that already exist instead of defining new ones for a given purpose.

Best wishes

Jonathan
_______________________________________________


--
*******************************************************
* Nan Galbraith        Information Systems Specailist *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                 (508) 289-2444 *
*******************************************************



_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to