Re: [CF-metadata] Convention attribute
Dear all The existing Unidata recommendation is OK and we could incorporate it into CF but it would help to be more precise, for instance: If the Conventions att includes no commas, it is interpreted as a blank-separated list of conventions; if it contains at least one comma, it is interpreted as a comma-separated list. Blank-separated lists are more CF-like - many CF attributes use that syntax - but obviously we can't insist that other conventions don't have blanks in their names, and it would be simpler therefore to use a comma-separated list for this attribute, despite the Unidata recommendation. I see no problem with allowing multiple conventions except the important proviso that if the file follows more that one convention it is the responsibility of the data-writer to ensure there is no inconsistency between the metadata following these conventions. That is, they must serve complementary purposes. It would be impossible to check this automatically so we have to depend on the data-writer doing it correctly. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Convention attribute
Hi all, my opinion is to keep with the current recommendation, which better supports automatic parsing and the existing conforming datasets. In particular, I would avoid any parsing rule for the conventions attribute, keeping its syntax as simple as possible (as Jonathan points out, blank-separated lists are more CF-like). I think it makes sense to require convention identifiers not to contain spaces (as usual in identifiers). Those conventions that have not followed Unidata recommendation may be dealt with on a transitional basis (e.g. by means of specific parsing exceptions), while they are aligned in a future revision. Best wishes, LB Il giorno 22/dic/2011, alle ore 10:11, Jonathan Gregory ha scritto: Dear all The existing Unidata recommendation is OK and we could incorporate it into CF but it would help to be more precise, for instance: If the Conventions att includes no commas, it is interpreted as a blank-separated list of conventions; if it contains at least one comma, it is interpreted as a comma-separated list. Blank-separated lists are more CF-like - many CF attributes use that syntax - but obviously we can't insist that other conventions don't have blanks in their names, and it would be simpler therefore to use a comma-separated list for this attribute, despite the Unidata recommendation. --- Dott. Lorenzo Bigagli Consiglio Nazionale delle Ricerche Istituto di Metodologie per l'Analisi Ambientale (CNR-IMAA) i: Area della Ricerca di Potenza, Contrada Santa Loja Zona Industriale, 85050 Tito Scalo (PZ), Italia t: +39 0971 427221 f: +39 0971 427222 m: lorenzo.biga...@cnr.it ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Convention attribute
Thanks Russ, Dave(s), Jonathan and Lorenzo - Thanks for the clarifications. I agree that it makes sense to require that convention names not contain spaces, and that it's easier (and more CF-like, hence better!) to parse space separated terms. Cheers - Nan The recommendation on the Unidata site for multiple conventions http://www.unidata.ucar.edu/netcdf/conventions.html is to use spaces rather than commas: It is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. In this case, the value of the `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks), for example :Conventions = XXX YYY ; On Dec/22/2011 6:01 AM, Lorenzo Bigagli wrote: Hi all, my opinion is to keep with the current recommendation, which better supports automatic parsing and the existing conforming datasets. In particular, I would avoid any parsing rule for the conventions attribute, keeping its syntax as simple as possible (as Jonathan points out, blank-separated lists are more CF-like). I think it makes sense to require convention identifiers not to contain spaces (as usual in identifiers). Those conventions that have not followed Unidata recommendation may be dealt with on a transitional basis (e.g. by means of specific parsing exceptions), while they are aligned in a future revision. Best wishes, LB Il giorno 22/dic/2011, alle ore 10:11, Jonathan Gregory ha scritto: Dear all The existing Unidata recommendation is OK and we could incorporate it into CF but it would help to be more precise, for instance: If the Conventions att includes no commas, it is interpreted as a blank-separated list of conventions; if it contains at least one comma, it is interpreted as a comma-separated list. Blank-separated lists are more CF-like - many CF attributes use that syntax - but obviously we can't insist that other conventions don't have blanks in their names, and it would be simpler therefore to use a comma-separated list for this attribute, despite the Unidata recommendation. -- *** * Nan Galbraith(508) 289-2444 * * Upper Ocean Processes GroupMail Stop 29 * * Woods Hole Oceanographic Institution* * Woods Hole, MA 02543* *** ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Convention attribute
It is easier (not by much, code-wise) to not to allow commas as delimiters, but if you want to allow for machine-recognition of convention names, how are you going to handle conventions that have spaces in their names? Telling everyone else to get rid of spaces isn't a practical solution, and you have just created a thornier problem for coders who have to figure out which way someone dealt with forbidden spaces. On 12/22/2011 10:18 AM, Nan Galbraith wrote: Thanks Russ, Dave(s), Jonathan and Lorenzo - Thanks for the clarifications. I agree that it makes sense to require that convention names not contain spaces, and that it's easier (and more CF-like, hence better!) to parse space separated terms. Cheers - Nan The recommendation on the Unidata site for multiple conventions http://www.unidata.ucar.edu/netcdf/conventions.html is to use spaces rather than commas: It is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. In this case, the value of the `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks), for example :Conventions = XXX YYY ; On Dec/22/2011 6:01 AM, Lorenzo Bigagli wrote: Hi all, my opinion is to keep with the current recommendation, which better supports automatic parsing and the existing conforming datasets. In particular, I would avoid any parsing rule for the conventions attribute, keeping its syntax as simple as possible (as Jonathan points out, blank-separated lists are more CF-like). I think it makes sense to require convention identifiers not to contain spaces (as usual in identifiers). Those conventions that have not followed Unidata recommendation may be dealt with on a transitional basis (e.g. by means of specific parsing exceptions), while they are aligned in a future revision. Best wishes, LB Il giorno 22/dic/2011, alle ore 10:11, Jonathan Gregory ha scritto: Dear all The existing Unidata recommendation is OK and we could incorporate it into CF but it would help to be more precise, for instance: If the Conventions att includes no commas, it is interpreted as a blank-separated list of conventions; if it contains at least one comma, it is interpreted as a comma-separated list. Blank-separated lists are more CF-like - many CF attributes use that syntax - but obviously we can't insist that other conventions don't have blanks in their names, and it would be simpler therefore to use a comma-separated list for this attribute, despite the Unidata recommendation. -- Jim Biard Government Contractor, STG Inc. Remote Sensing and Applications Division (RSAD) National Climatic Data Center 151 Patton Ave. Asheville, NC 28801-5001 jim.bi...@noaa.gov 828-271-4900 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Convention attribute
On 12/22/2011 2:11 AM, Jonathan Gregory wrote: Dear all The existing Unidata recommendation is OK and we could incorporate it into CF but it would help to be more precise, for instance: If the Conventions att includes no commas, it is interpreted as a blank-separated list of conventions; if it contains at least one comma, it is interpreted as a comma-separated list. Blank-separated lists are more CF-like - many CF attributes use that syntax - but obviously we can't insist that other conventions don't have blanks in their names, and it would be simpler therefore to use a comma-separated list for this attribute, despite the Unidata recommendation. I see no problem with allowing multiple conventions except the important proviso that if the file follows more that one convention it is the responsibility of the data-writer to ensure there is no inconsistency between the metadata following these conventions. That is, they must serve complementary purposes. It would be impossible to check this automatically so we have to depend on the data-writer doing it correctly. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata I think this would solve the problem: If the Conventions att includes no commas, it is interpreted as a blank-separated list of conventions; if it contains at least one comma, it is interpreted as a comma-separated list. I could also point out that reading software has a list of conventions it recognizes, so in practice one takes the result of this parsing and compares to a known list. also, the netcdf-4 data model allows attribute values to be a 1-d array of Strings. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Convention attribute
Russ (and thus core netcdf) has always been explicit about space-delimited conventions, so really there shouldn't be any conventions with spaces in the names. On the other hand, we have adopted the technique of using the convention name as a pattern to match against the convention attribute, so that we do not care about delimiters. This, of course, will fail if someone has a convention name that is a substring of another convention name, and that convention is not a subset of the convention with the longer name. Benno On Thu, Dec 22, 2011 at 10:42 AM, Jim Biard jim.bi...@noaa.gov wrote: It is easier (not by much, code-wise) to not to allow commas as delimiters, but if you want to allow for machine-recognition of convention names, how are you going to handle conventions that have spaces in their names? Telling everyone else to get rid of spaces isn't a practical solution, and you have just created a thornier problem for coders who have to figure out which way someone dealt with forbidden spaces. On 12/22/2011 10:18 AM, Nan Galbraith wrote: Thanks Russ, Dave(s), Jonathan and Lorenzo - Thanks for the clarifications. I agree that it makes sense to require that convention names not contain spaces, and that it's easier (and more CF-like, hence better!) to parse space separated terms. Cheers - Nan The recommendation on the Unidata site for multiple conventions http://www.unidata.ucar.edu/**netcdf/conventions.htmlhttp://www.unidata.ucar.edu/netcdf/conventions.html is to use spaces rather than commas: It is possible for a netCDF file to adhere to more than one set of conventions, even when there is no inheritance relationship among the conventions. In this case, the value of the `Conventions' attribute may be a single text string containing a list of the convention names separated by blank space (recommended) or commas (if a convention name contains blanks), for example :Conventions = XXX YYY ; On Dec/22/2011 6:01 AM, Lorenzo Bigagli wrote: Hi all, my opinion is to keep with the current recommendation, which better supports automatic parsing and the existing conforming datasets. In particular, I would avoid any parsing rule for the conventions attribute, keeping its syntax as simple as possible (as Jonathan points out, blank-separated lists are more CF-like). I think it makes sense to require convention identifiers not to contain spaces (as usual in identifiers). Those conventions that have not followed Unidata recommendation may be dealt with on a transitional basis (e.g. by means of specific parsing exceptions), while they are aligned in a future revision. Best wishes, LB Il giorno 22/dic/2011, alle ore 10:11, Jonathan Gregory ha scritto: Dear all The existing Unidata recommendation is OK and we could incorporate it into CF but it would help to be more precise, for instance: If the Conventions att includes no commas, it is interpreted as a blank-separated list of conventions; if it contains at least one comma, it is interpreted as a comma-separated list. Blank-separated lists are more CF-like - many CF attributes use that syntax - but obviously we can't insist that other conventions don't have blanks in their names, and it would be simpler therefore to use a comma-separated list for this attribute, despite the Unidata recommendation. -- Jim Biard Government Contractor, STG Inc. Remote Sensing and Applications Division (RSAD) National Climatic Data Center 151 Patton Ave. Asheville, NC 28801-5001 jim.bi...@noaa.gov 828-271-4900 __**_ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/**mailman/listinfo/cf-metadatahttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Dr. M. Benno Blumenthal be...@iri.columbia.edu International Research Institute for climate and society The Earth Institute at Columbia University Lamont Campus, Palisades NY 10964-8000 (845) 680-4450 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Convention attribute
Dear all This is certainly a lively thread! :-) An array of strings would be nice but I don't think we should do that because it's not compatible with the Unidata convention and it depends on the non- classic netCDF model. In this case we can probably get by without it. While we can't control the names of netCDF conventions in general, and it appears that Unidata have not done so, CF could impose such a rule, as John suggests. That is, we could state that if a convention is to be regarded as compatible with CF, it must have a name with no spaces it. Then we can make the Conventions attribute a blank-separated list safely. Would that be acceptable? Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
