i may be missing a key organizational imperative, but it will be helpful for all of us to understand I think. To review the bidding:
On Jan 12, 2012, at 07:15, Nan Galbraith wrote: > Maintaining a gazetteer seems a little outside the scope of CF - wouldn't it > be preferable to require (or at least allow) an attribute for the "region" > variable pointing to an external vocabulary? On Jan 12, 2012, at 08:45, Lowry, Roy K. wrote: > However, in the case of CMIP5 I doubt if any published resource will fulfil > their requirements because the spatial objects are sections defined by the > project, which are unlikely to be included in any resource originating > outside the project. Therefore they need their own project-specific resource > and I can’t see any alternative to this being governed and served by CF. On Jan 12, 2012, at 09:03, Jonathan Gregory wrote: > Dear Alison > >> The CMIP5 regions I was thinking of were the names of various sea channels >> and straits. > > I agree that it makes sense to add the CMIP5 channels and straits to the CF > region list. Thanks. What is it about the CMIP5 project that makes it (uniquely?) supported by the community resource CF? Generally, if a project that needs a project-specific resource, the project creates that resource, right? In this day and age, creating a gazzetteer, or equivalent resource of terms, is pretty trivial even without programming expertise. So I go back to Nan's input, and reply "Yes -- it would be preferable to require an attribute for the region variable pointing to the external vocabulary." Or at least, pointing to the vocabulary. Even if CF is the one that maintains the vocabulary (for its own purposes, or for this project), including region names as part of the CF conventions seems idiosyncratic rather than systematic. John John Graybeal <mailto:[email protected]> 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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
