Nan,
Another possibility to consider is the notation
:Conventions = "A/B" ;
for data that conforms to the "A" conventions and also to more
restrictive "B" conventions, which in this case must be a strict
extension of the "A" conventions. See the text on the netCDF
Conventions site
http://www.unidata.ucar.edu/netcdf/conventions.html
(and in the documentation for the "Conventions" attribute) where it
says:
It may be convenient ... to use a hierarchical structure for general
conventions and more specialized conventions. For example, if a group
named XXX agrees upon a set of conventions ..., they may describe the
agreed-upon conventions in a document associated with the name "XXX",
and files that followed these conventions would contain the global
attribute
:Conventions = "XXX" ;
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" ;
--Russ
_____________________________________________________________________
Russ Rew UCAR Unidata Program
russ at unidata.ucar.edu
http://www.unidata.ucar.edu
> This is a multi-part message in MIME format.
>
> --===============1484141327359310300==
> Content-type: multipart/alternative;
> boundary="Boundary_(ID_fXE2mcdu81cfaBoVH0dzxg)"
>
> This is a multi-part message in MIME format.
>
> --Boundary_(ID_fXE2mcdu81cfaBoVH0dzxg)
> Content-type: text/plain; charset=ISO-8859-1; format=flowed
> Content-transfer-encoding: 7BIT
>
> 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
> >
> >
>
> --Boundary_(ID_fXE2mcdu81cfaBoVH0dzxg)
> Content-type: text/html; charset=ISO-8859-1
> Content-transfer-encoding: 7BIT
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Hi Nan,<br>
> <br>
> 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")<br>
> <br>
> As an answer to your immediate question -- my 2 cents:<br>
> <ol>
> <li>It would be best not to "break" the CF conventions, so retaining
> simply the unadorned Conventions = "CF-1.4" seems the best choice.</li>
> <li>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.<br>
> </li>
> <ul>
> <li> OceanSitesConventionsVersion = 1.0;<br>
> </li>
> </ul>
> </ol>
> ====<br>
> 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<br>
> <blockquote>.Profile = "XBT-1.0" or .Community_Profile or whatever?<br>
> </blockquote>
> 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.<br>
> <br>
> Should we open a trac ticket?<br>
> <br>
> - Steve<br>
> <br>
> ==================================<br>
> <br>
> Nan Galbraith wrote:
> <blockquote cite="mid:4A9D25D0.4040407 at whoi.edu" type="cite">Hello all
> -
> <br>
> <br>
> Although we have not had any more input on the best way to
> <br>
> declare a community profile in a CF-compliant file, I still have a
> <br>
> question. I think this also relates to the namespace ticket (#27)
> <br>
> on the trac system.
> <br>
> <br>
> The trac ticket mentions that using comma-separated conventions is the
> <br>
> method suggested in the NetCDF documentation, although the page
> <br>
> referenced,
> <a class="moz-txt-link-freetext" href="http://www.unidata.ucar.edu/software/n
> etcdf/guidef/guidef-13.html">http://www.unidata.ucar.edu/software/netcdf/guid
> ef/guidef-13.html</a>,
> <br>
> is not a working link.
> <br>
> <br>
> The CF compliance checker chokes on a compound conventions
> <br>
> attribute, like Conventions = "CF-1.4, OceanSITES-1.0" - is this the
> accepted
> <br>
> method of declaring multiple conventions, or do I need to stick with
> <br>
> a pristine "CF-1.4" and declare the OceanSITES compliance in a separate
> <br>
> attribute, perhaps, as Derrick suggested, using a "profile" attribute?
> <br>
> <br>
> Since most of the OceanSITES participants are now generating data in
> <br>
> this format, and since we are requesting that they check their files
> for
> <br>
> CF compliance, I'd really like to know the preferred way to do this.
> <br>
> <br>
> Again, the OceanSITES spec is completely CF compliant, it just imposes
> <br>
> more restrictions, essentially simplifying CF for use with in situ data
> (although,
> <br>
> IMHO, it's probably quite a bit more rigid than is really necessary). &n
> bsp;
> <br>
> Thanks -
> <br>
> Nan
> <br>
> <br>
> <br>
> John Caron wrote:
> <br>
> <blockquote type="cite">Derrick Snowden wrote:
> <br>
> <blockquote type="cite">... 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
> <br>
> <br>
> .Conventions = "CF-1.4, XBT-1.0" or
> <br>
> <br>
> .Conventions = "CF-1.4"
> <br>
> .Profile = "XBT-1.0" or .Community_Profile or whatever?
> <br>
> <br>
> 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.
> <br>
> </blockquote>
> Hi Derrick:
> <br>
> <br>
> ...
> <br>
> <br>
> 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.
> <br>
> <br>
> With regard to
> <br>
> <br>
> Conventions = "CF-1.4, XBT-1.0"
> <br>
> <br>
> 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.
> <br>
> <br>
> We are doing something like this for OceanSITES, and yes, the
> <br>
> extra information in the Conventions attribute is important to us.
> <br>
> <br>
> The files are CF compliant, so 'CF-1.4' in this attribute tells the
> <br>
> user he can use any code that reads CF to read them. The
> <br>
> 'OceanSITES 1.1' in the attribute tells the user about some additional
> <br>
> restrictions and assumptions he can make.
> <br>
> <br>
> For better or worse, we hard-wire some features (e.g. reference date),
> <br>
> and add some restrictions (e.g. units) , in order to simplify the code
> that
> <br>
> reads these files. This makes NetCDF a little less daunting for people
> <br>
> who haven't used it before, or who might find its flexibility a problem
> <br>
> rather than a feature.
> <br>
> <br>
> - Nan
> <br>
> </blockquote>
> <br>
> <br>
> </blockquote>
> </body>
> </html>
>
> --Boundary_(ID_fXE2mcdu81cfaBoVH0dzxg)--
>
> --===============1484141327359310300==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --===============1484141327359310300==--
Received on Tue Sep 01 2009 - 13:44:04 BST
