Continuing on the same subject ...
Could I emphasise first that I agree that something needs to be done, as we
want to add many parameters to the table, and the current arrangements will not
be able to deal with it.
With regard to Steve's comment about mistakes, I agree, and we already have a
means to do that. The "alias" entry in the standard name xml is a way to link
an old name for a quantity to its new name, and we have used it several times.
I'd like to make this proposal, an elaboration of what I wrote before:
(0) We retain the existing arrangement for adding standard name as proposed to
the email list, which should be adequate in many cases involving only a few
new standard names.
(1) Projects wanting to develop their own list of standard names should produce
xml tables with the same schema as the central table (containing standard name,
canonical units, description).
(2) Each such project should have a unique name, and the project tables should
be linked with those names from the CF home page (like conventions of netCDF).
That means the project tables will all be public.
(3) Project tables should avoid including new names for quantities which already
have standard names in the central tables or in any of the existing project
tables.
(4) Names in the project table which are not in the central table should have
a prefix of the name of the project which defined them. One possible syntax
would be, for instance, "my_project/my_standard_name". There would be no need
for an attribute in the netCDF file to identify the standard name table, as
the project name will refer to a table which is linked from the CF
website. That makes the files more "future-proof" (since URLs often change).
(5) When names are adopted from project tables into the central table, with or
without changes, an alias will be made to the name in the project table i.e.
if a central standard name of new_standard_name is defined for the quantity
which was named my_project/my_standard_name, the latter will become an alias of
the former in the central table.
(6) Maintainers of project tables should consider deleting or updating entries
which have been given names in the central table.
This would allow projects to do their own thing, but also means that we can
continue to consider how to incorporate new lists into the central table.
An existing example something rather like this is the aquaplanet experiment
(APE). APE defined ape_names for its quantities. Most, but not all, of them are
standard names. (See
http://www-pcmdi.llnl.gov/amip/ape/ape_data_specs.html.)
If we had a policy like the above, we should now be thinking about defining
central standard names for those ape_names which don't have them. One example
is "Zonal velocity tendency - Gravity Wave Drag". We could easily define a
standard name for that, following existing guidelines. The problem is (this is
not a criticism of APE in particular) that there is no impetus or effort to do
so. Hence it is perfectly possible that another project may choose their own
local name for this quantity. Then we will have two names for it, which will
be a problem for users of data from both. The original point of standard names
was to avoid this, by not permitting there to be alternative names. What can
we do to stop it happening?
Finally, there is a possibility that names might be defined which don't
conform to CF, especially if the names include information which belongs in
cell_methods (e.g. time-mean) or coordinates (e.g. 10 m above the ground).
How would that be checked?
Cheers
Jonathan
Received on Thu Jun 24 2004 - 06:57:18 BST
