Hello,
I think there is another concrete example of a profile/extension that
could provide some input on how this should be handled? Or at least
shows how it is handled in this particular case. (Sorry if this has
come up before).
All the data prepared for CMIP5 will go through CMOR. Applications
using this data can
1. assume certain characteristics which are more limited than full blown
CF (e.g. one variable per file, dimensions in a defined order) - I
*think* this makes it a profile.
2. use CMOR specific attributes, some of which are from controlled
vocabs, to help identify/describe the data (e.g. 'experiment',
'model_id'), or identify the rules used to constrain the output
('project_id', 'table_id') - I *think* this makes it an extension.
3. 'rely' on a naming convention for files - though obviously this one
is easy, in principle, to break, though in practice I don't know if it
is very often. (but this is kind of a side track)
I *think* the way to recognise that a file has been produced by cmor is
through the 'cmor_version:'. So I think in this case its more like
Steve's proposal of 'OceanSitesConventionsVersion'. I don't know if
this is/will be used in practice (e.g. by the CMIP5 file ingestion
software) to help process data.
Obviously anyone who knows more about CMOR and using data produced from
CMOR please correct anything I have wrong.
Jamie
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of John Caron
> Sent: 03 September 2009 15:29
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Conventions (vs. Community
> Profiles),and CF-checker
>
> Hi Jonathan:
>
> Jonathan Gregory wrote:
> > Dear all
> >
> > I confess to not having read what the user guide says (at
> least, not
> > recently) and I have copied it below in case others would
> like to be reminded as well.
>
> Russ and I are a bit unclear if there are older versions that
> say something different.
>
> >
> > This suggests that Nan's extra conventions for oceansites would
> > correctly be denoted "CF-1.4/OceanSITES-1.0", since
> oceansites accepts
> > all of CF and adds some more. We could, for instance, amend the CF
> > convention to recommend this format for additional conventions that
> > explicitly say they adopt all of CF and add some more. I am
> sure the
> > checker could be amended to ignore whatever follows / in
> the Conventions attribute.
> >
> > As a matter of policy, I would hope that subconventions like this
> > would only be added if the extra conventions were too
> > application-specific to be of general use. New ideas which
> could apply
> > in other areas could usefully be added to the main CF standard.
>
> agree, we should encourage adding generally useful things to the core.
>
> >
> > The user guide doesn't say anything about spaces. It
> doesn't prohibit
> > them, but it does talk about conventions names being filenames.
> > Although filenames containing spaces are possible, they're
> a nuisance
> > on Unix, and it seems to me they would be a hazard in this context.
> > People often put in extra spaces, or leave out spaces, fairly
> > arbitrarily in strings, and if they are significant that
> would be an
> > error. Wouldn't it be better to recommend against spaces in
> conventions names in the netCDF user guide?
>
> yes, i agree to recommend against spaces, just worried about
> whats already out there. in fact, a brief survey shows that I
> may be the main offender (sheepish grin)!
>
> >
> > This user guide convention with / is for subconventions. It doesn't
> > deal with the situation where several separately developed
> conventions
> > are being used, and you might want to put them in a
> blank-separated or comma-separated list.
> > I don't think we should allow that in the Conventions
> attribute unless
> > and until we'd decided how to resolve conflicts between these
> > conventions. (There are no conflicts with a subconvention that
> > explicitly accepts all the of the standard to which it is adding.)
>
> i think the common use case is this: a group already has
> their data using their own convention, possibly even
> documented(!). now they want to get on the CF bandwagon so
> they are going to try to be CF compliant without breaking
> their existing software. I dont see how we can disallow that,
> since CF explicitly allows other metadata. if there are
> conflicts, then I agree this should not be allowed. it does
> argue for us to resolve the namespace problem, eg CF:attname = value.
>
> >
> > Best wishes
> >
> > Jonathan
> >
> >>From
> >>http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html
> #Attribute
> >>-Conventions
> >
> > If present, 'Conventions' is a global attribute that is a character
> > array for the name of the conventions followed by the
> dataset, in the
> > form of a string that is interpreted as a directory name
> relative to a
> > directory that is a repository of documents describing sets of
> > discipline-specific conventions. This permits a
> hierarchical structure
> > for conventions and provides a place where descriptions and
> examples
> > of the conventions may be maintained by the defining
> institutions and
> > groups. The conventions directory name is currently interpreted
> > relative to the directory pub/netcdf/Conventions/ on the
> host machine
> > ftp.unidata.ucar.edu. Alternatively, a full URL
> specification may be
> > used to name a WWW site where documents that describe the
> conventions are maintained.
> >
> > For example, if a group named NUWG agrees upon a set of conventions
> > for dimension names, variable names, required attributes,
> and netCDF
> > representations for certain discipline-specific data
> structures, they
> > may store a document describing the agreed-upon conventions in a
> > dataset in the NUWG/ subdirectory of the Conventions directory.
> > Datasets that followed these conventions would contain a
> global Conventions attribute with value "NUWG".
> >
> > Later, if the group agrees upon some additional conventions for a
> > specific subset of NUWG data, for example time series data, the
> > description of the additional conventions might be stored in the
> > NUWG/Time_series/ subdirectory, and datasets that adhered to these
> > additional conventions would use the global Conventions
> attribute with
> > value "NUWG/Time_series", implying that this dataset adheres to the
> > NUWG conventions and also to the additional NUWG
> time-series conventions.
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Thu Sep 03 2009 - 09:36:51 BST
