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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Received on Sat May 15 2010 - 06:08:30 BST
