Dear all, first of all let me say that I truely appreciate the careful discussion my proposal has initiated. This indeed is probably the most convincing reason why CF has been accepted already in several parts of the community.
Steve made a very nice distinction to clarify what my suggestion of <project>_standard_names was really about. In fact it really had elements of his (1) and (2) approaches. Let me re-iterate on both of them: (1) for the process of defining new standard names, I believe the suggestions that were made all point into the right direction. Personally, I like the standard_name: "proposed: ...." approach. Any tool could then easily test if the string behind "proposed" exists in the current standard_name table or not. If it doesn't, a warning occurs but no error. Hence, no modification would be required to any existing data set, albeit these files could be upgraded by removing the "proposed" string once the name has been accepted. I also see the point that communities should enhance their efforts to have names defined before running their experiments. However, practical experience rarely allows for this and we can only hope that over time there will be enough standard names available to cover almost all aspects of such experiments (in the atmospheric chemistry domain we have already come quite far now). (2) the "private" name space was more central to my suggestion. Steve made cautioning comments about the development of non-standard GRIB tables, and indeed these are a great pain. However, there is a fundamental difference here in that netcdf files will always be amenable to at least some interpretation provided that "good" metadata is provided, while one is completely lost with a GRIB file if the code table cannot be found (we experienced this the hard way when we first added chemical species into the ECHAM model). The discussion so far has viewed my proposal mainly from the CF perspective. I would like to invite you again to take the view of the project coordinator for a minute. Experience shows that about 95% or more of the preparations for new experiments go into scientific validation of the model and making sure it runs at all and hopefully reasonably efficient. Then someone at a meeting gets up and displays a long list of seemingly glibberish semantic phrases which are to be proposed as standard names in some weird "convention". Typically this presentation is given during the last 5 minutes of a meeting and 50% of the audience have already left for the airport. Consequently, the coordinator (or some nice fellow supporting him/her) has to deal with this standardisation on his/her own (while at the same time preparing their own model). Finally, a proposal for new standard names is submitted and by the time the discussion is over 30% have passed unaltered, 60% require modification and 10% are rejected. At that point in time most model runs have been submitted. Now: what do you do? I guess each and every one of these coordinating fellows/fellas will be happy if he/she can assure that all data in the archive are not corrupted, the models have worked and the analysis that was planned can be performed. Proper archiving and interoperability (still) come as an afterthought. [I only hope this doesn't sound too negative, I may have been watching too much cabaret lately ;-)] -- back to the actual suggestion: what I wanted to express with my proposal is that we should find a way to acknowledge that someone has tried to establish new standard names while at the same time the "pure" standard should not be corrupted. The proposal of using "proposed:" actually captures this very nicely. By the same token we could even go as far as to allow the keyword "private:" in the standard_name string (instead of defining a new <project>_standard_name). Yes: it does to some extent weaken the stringency of a standard_name, but only on the surface. In reality I believe such qualifiers could even strengthen the concept. We could require that a "project" attribute must be part of the global attributes if the "private" qualifier is used and the project attribute must point to a web resource where information on the project is given (perhaps one could even think of a central "project" database with a simple registration process to make eternity easier to achieve). As project manager you may be glad to surf on the well-designed concept that CF and the standard names provide and there is currently no standardized way to do this. By allowing such qualifier keywords to the standard_name attribute, nothing would change in terms of "official" standards (as these are the standard_names without any qualifier) while it would become a lot easier for newcomers and other groups to take advantage of the concept. In effect this would be a neat way to address the needs both of the operational community, where it is very important to rely on the long lifetime of a name and of the "experimental" community, which needs flexibility more than anything else, but where interoperability can also play a very important role in the future. Cheers, Martin ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
