Dear Bryan and Jonathan,
thanks for your answers. While I fully appreciate your reluctance to
add "external" namespaces to the standard CF file (I would probably react
similar if such a proposal was put forward to me), I still believe there is
something missing in the concept and/or work flow to really simplify life
and establish the standard_names as a true community standard which can be
put to use. The concept by John Graybeal doesn't help, because you still
need to manually establish the connection between variable names and
standard names, and this must be redone whenever the CF file changes (John
told me that perhaps in the future this could be facilitated in that
"updates" may become possible, but at present you have to go through the
whole link process again when a new CF table is released). That concept is
great for step 2, i.e. if you have different connections (in this case
different set of variable names), you can establish relationships between
these. But what I am worried about now is step 1.
It's not that I shy away from editing the XML file and adding the
variable names for the project use once. But I can almost guarantee that
this will then be cast in stone and we will never update to any newer CF
table (and worse even, over time different groups may generate different
versions of such a merged table). In contrast, if these tags were contained
in the default file, it would be easier to follow any new developments.
I don't think we are talking about a large number of sets of "common
variable names" here: there may be amip (which I believe is still widely in
use; ECHAM for example uses those in all its netcdf output), there would be
htap and aerocom for chemistry (and I am optimistic that we can persuade
other projects to adopt those for atmospheric chemistry, for example in
upcoming IPCC AR5 simulations), and there may be 2 or 3 others for
climate/meteorology and ocean (and if there are more they can't be called a
standard set and thus shouldn't be included). A strong criterion should be
that these variable names are adopted in large international programmes
where a good fraction of the respective community is engaged in.
It is great to see the great involvement that you all put into this and
I thank you for this effort. Some of the discussions on the list have become
almost philosophical and I sure have learnt quite a bit through them. Yet,
from the pure practical angle I can't see yet, how the standard names can
become well established if we don't facilitate the connection to "real life"
name spaces (and at least from my programming experience these are typically
variable names). It's well possible that I am too old-fashioned in my
programming paradigm, but then I see myself more as a scientist than a
software developer, and I know that (at least in the atmospheric chemistry
field) the same is true for almost anyone who is a potential "customer" of
standard names. Again, it's step 1 that I am concerned about, which is to
ease the process of creating files that have these standard names in them.
Once this is sufficiently spread, the time for the great universal analysis
tools can come, and these tools would have the chance to identify variables
by their standard_name alone. Caveat: we are using CMOR in HTAP and this
helps a lot, but (and I don't hink this is such an exceptional situation)
when we were producing our first output files, the chemistry names were
still under discussion, which means we are now using slightly different
"standard_names" which I don't like at all. The standard_name <--> variable
mapping which I propose would greatly help to clean this up (and to bring
additional output which was not or could not be generated through CMOR; for
example vertical column output; up to the standard as well).
Having said all this, I would like to emphasize that this is of course a
personaly biased view and may be too determined by the moment's needs.
However, I hope you agree with me that this problem shows that something is
still missing in the concept and that some effort should be made to ease the
spreading of CF standard names.
Best regards,
Martin
PS: what I meant by "syntax definition file" came up when I used IDL's
IDLffxmlSAX parser to scan the contents of the cf-standard-names.xml file.
The message was:
% IDLFFXMLSAX::PARSEFILE: Parser SAX warning: File: , line: 0, column: 0 :
An exception occurred!
Type:RuntimeException, Message:Warning: The primary document
entity could not be opened.
Id=/raid/htap/users/htap00/idl/lib/martin_schultz/CFStandardNameTable-1.1.xs
d
-----Original Message-----
From: Bryan Lawrence [mailto:b.n.lawrence at rl.ac.uk]
Sent: Wednesday, April 09, 2008 9:59 PM
To: cf-metadata at cgd.ucar.edu
Cc: Schultz, Martin; Alison Pamment
Subject: Re: [CF-metadata] what standard names are for
Hi Martin
> although the subject has been changed I feel that this discussion
> has been closely related to my recent question about adding extra tags
> in the XML file and mdefining a way how these can survive. To ask
> again much more specifically this time:
> (1) who is maintaining the xml file (and the asociated syntax
> definiiton file which I could not locate on the web)?
We (BADC) and specificaly Alison Pamment maintain the CF standard names. We
maintain the authorative version at cfconventions.org, and the
non-authorative (but version controlled) list via vocab.ndg.nerc.ac.uk.
There is no associated syntax definition file, if I have understood what you
mean by that.
> (2) if I would send an edited XML file which included <htap> tags to
> contain the TFHTAP multi-model assessment variable names (just like it
> is the case for <amip> at present) to the person named in (1): would
> this xml file be further maintained and future updates would keep this
> additional tag?
I don't think we're currently in the business of maintaining other folks
namespaces. and particularly not by locking into any specific xml syntax. I
think the earlier response to your message from John Graybeal is a better
way forward for you ...
That said, the cf common concept (a current proposal thread) could also
provide a useful mechanism which we (CF) could maintain. However, that
doesn't exist now!
> If these two points can be satisfied, it would constitute a great
> step forward for me to actually make use of the cf standard names and
> other standards around it. And I believe that this will also
> proliferate into many other international (atmospheric chemistry)
> modelling initiatives, because many groups are involved in HTAP. If
> not, then I fear that the HTAP community for example will quickly
> loose interest to follow standard names as there will for a long time
> be no "super software" that eliminates the need to know the actual
> variable names in order to process the data.
>
> Sorry for being somewhat pushy on this, but I need to get some work
> done here.
As do we all :-)
best wishes,
Bryan
--- and email by Jonathan Gregory:
Dear Martin (just to you)
I'm not quite sure what you mean - sorry. Are you asking about extra tags in
the standard_name.xml file? This file is maintained by Alison Pamment and
Velimir Mlaker and its syntax is described in Appendix B of the CF standard.
However, personally I don't think we should add more tags in that centrally
maintained file. I actually would prefer that we removed the PCMDI and GRIB
info, which is out of date. Would it not be better for separate files to be
maintained by PCMDI, HTAP and others, giving the CF equivalences of their
codes?
Best wishes
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5634 bytes
Desc: not available
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080410/ce533c6d/attachment-0002.bin>
Received on Thu Apr 10 2008 - 01:13:25 BST
