I am interested in the implications for defining multiple conventions in the same file. As a data creator, what am I asserting by defining my file with multiple conventions?
It could be said that the conventions attribute provides an implicit name space for the controlled terms it defines. This enables a data consumer to assign meaning to the terms defined by the convention which exist within a particular file. If I have one convention, I can pattern match all the attributes and explicitly link them to a convention. All the ones that don't match are user defined, and not part of the convention. Does this scale to having multiple conventions defined? Do conventions maintain mutually exclusive vocabularies? I don't think they do. Where vocabularies share terms, is there oversight that ensures that shared terms are defined the same way? If I assert that two conventions are being used, does that mean that I have checked that my file contains no attributes which are ambiguously defined? If I want to use a term which is ambiguously defined, can I do this effectively? There seems to be significant potential for confusion here; I think care is required. mark -----Original Message----- From: cf-metadata-boun...@cgd.ucar.edu on behalf of John Graybeal Sent: Thu 22/12/2011 22:27 To: Jim Biard Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] Convention attribute Perhaps this problem can be resolved if we carefully distinguish between the convention *identifier* in the Conventions attribute, and the convention name (which can be in any other attribute, like Convention_Names or Metadata_Conventions). For the names we could specify either attribute, or both, or be silent. I'd argue that good practices suggest that the identifier should be created to support automatic parsing of the netCDF Conventions attribute. Such a good practice would eliminate spaces from the identifier, given current guidance. In this case I'd argue the value of supporting automated and deterministic detection of conventions, outweighs the cost of insisting the identifier can be free-form text. And although if I ran the world I'd standardize on the attribute for the full convention names and how to delimit them, it won't bother me too much if by our silence we force a human reader to scan through the rest of the attributes to find the full names of all the applicable conventions. John As in the example I tossed out earlier, OceanSITES 1.1" but that isn't the complete name of the convention I'm thinking. On Dec 22, 2011, at 14:01, Jim Biard wrote: > Seems a bit extreme to say that a convention is not compatible with CF just > because it has a name with spaces in it. Apart from the Conventions > attribute, a file can be completely conformant with both CF and one or more > other conventions. I feel like our goal should be to maximize the ability of > people to indicate what conventions are in use in their files. If we don't > allow this attribute to somehow contain the names of all of the conventions, > it will mean that other attributes will be used to contain the names of the > other conventions. We will then have a hodgepodge of attributes that need to > be checked in order to find out what conventions are applicable. In the > spirit of encouraging cooperation, let's allow this attribute definition to > be flexible enough to accommodate non-CF approaches to doing things. Doesn't > mean we have to do it everywhere. > > Grace and peace, > > Jim > > On 12/22/2011 4:03 PM, Jonathan Gregory wrote: >> 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 > > -- > 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 John Graybeal <mailto:jgrayb...@ucsd.edu> phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
