Dear Jonathan, Steve, Roy ...
I share Jonathan's concerns. Overlapping name tables should be avoided.
Dividing the current standard name table into mutual exclusive domains with
each an accepted "moderator" group would be a step forward in extending the
CF model. There would be a small fixed core of shared common standard_names
implicit to the CF standard. Extra domains could be declared as needed.
These extension tables should follow the existing naming rules and should be
registered in a persistent central registry, e.g. at ucar or maybe unesco.
- I recently learned UNESCO is setting up such a registry which allows
scientific communities to maintain their register with name table(s). -
And I would like to suggest the use of the namespace principle used in xml.
This would allow for several namespaces to be used in the same file, e.g.
// global attributes:
:Conventions = "CF-1.0" ;
:standardNameExtensions =
"ns:met="
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/meteo_names.xml,
ns:hyd="
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/hydro_names.xml"
.........
// Steve's example moved to an extension table
float tnt(latitude, longitude) ;
tnt:long_name = "tendency of air temperature due to diabatic
processes" ;
tnt:standard_name =
"met:tendency_of_air_temperature_due_to_diabatic_processes" ;
tnt:units = "K s-1" ;
// example below is based on an entry in the current BODC dictionary
float (latitude, longitude)thar ;
thar:long_name = "Tritium/hydrogen atomic ratio" ;
thar:standard_name = "hyd:3H1HMXTX" ;
thar:units = "Tritium units (10**18H/Tr)" ;
// time is in the core standard name table
double time(time);
time:standard_name = "time" ;
time:units = "hours since 1999-01-01 00:00" ;
==========
best regards,
Pieter Haaring
Dutch Ministry of Transport, Public Works and Water Management
National Institute for Coastal and Marine Management (RIKZ)
-----Oorspronkelijk bericht-----
Van: Jonathan Gregory [mailto:j.m.gregory at reading.ac.uk]
Verzonden: Wednesday June 23, 2004 20:56 PM
Aan: cf-metadata at cgd.ucar.edu
Onderwerp: [CF-metadata] detaching the standard name table
Dear Steve et al.
I agree with the goal that CF should be a broad standard and it would be a
great pity if the standard name table were an obstacle to that. I think that
we
should in any case make it perfectly clear that files are compliant without
standard names. Like most CF features, they are optional. This should be
stated
prominently e.g. at the top of the standard name table, on the CF home page,
or
in the conventions document.
I agree that user groups of CF should develop their own additions to the
standard name table. However, I share the concern of Roy's second paragraph,
that if there is a profileration of standard name tables, their entries will
overlap. As I see it, the main point of standard names is that they should
allow data from different communities and projects to be exchanged. If
groups
have separate tables, this is not achieved, and standard names are useless
as
such. I think it would be inappropriate to call them "standard names"; maybe
we
ought to have a new attribute for them.
Can we understand what problems we have with the current arrangement? One of
them is that it's slow. When questions are raised about standard names, it
is
usually me who answers them; there's only one of me (I would be very happy
if
more people joined in), and I agree with your assertion that I don't want to
be
a naming authority for all physical parameters! A user group discussing
among
themselves might much more quickly put together a list of what they need.
This
has happened, for instance, with an ice sheet modelling initiative and with
PRISM (though the results of these two efforts haven't yet been proposed for
incorporation).
The important step is what happens next. If a list of new standard names is
proposed, we might ask these kinds of question
(1) What does this mean? Is it correctly and clearly described?
(2) Is this the same thing as such-and-such which we already have in the
table?
(3) Can we make this consistent with how we have named other such
quantities?
The third kind of question could certainly be avoided if the standard name
table were split up. I believe that consistency is useful in order to
understand the names and to make it easier to add new ones, but for better
or
worse their style largely reflects decisions I have made, and I might well
be
wrong about them.
The other two kinds of question cannot be avoided if exchange of data among
different groups is going to work. Answering these questions is *difficult*.
It
requires a lot of intellectual effort. Maybe that's the bottleneck.
Devolving
standard name tables does not answer these questions - it just sidesteps
them.
So it would certainly save effort, but the result would be less useful.
If we have a range of tables, I would therefore advocate:
* There should still be a central standard name table, into which others
should
be mapped or incorporated, as Roy has offered.
* The developers of tables should be very strongly urged carefully to check
whether quantities they require already have standard names, and only
include
ones that don't in their tables.
* They should provide descriptions of the quantities in their tables.
* The tables should be linked from the CF website. That way we can see what
is
being worked out, and we'll be in a much better position to consider how we
can
map/incorporate them into the central table.
These actions might help to avoid fragmentation and to engage groups in
trying
to use a common vocabulary at an early stage, in the way Roy suggests. The
OTS
list is a good example, for instance. Most of these quantities do already
have
standard names. It's a small list and we could certainly add names for the
other ones. OTS could propose some, following the guidelines. That seems a
much
better route to me than introducing a new table. It would be very valuable
if
timeseries from ocean buoys could be easily compared with ocean models; if
they
don't use the same standard names, this will be inhibited.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Disclaimer
************************************************************************
Aan dit bericht kunnen geen rechten worden ontleend. Dit bericht is
uitsluitend bestemd voor de geadresseerde. Als u dit bericht per abuis
hebt ontvangen, wordt u verzocht het te vernietigen en de afzender te
informeren. Wij adviseren u om bij twijfel over de juistheid of de
volledigheid van de mail contact met afzender op te nemen.
This message shall not constitute any rights or obligations.
This message is intended solely for the addressee.
If you have received this message in error, please delete it and
notify the sender immediately. When in doubt whether this message
is correct or complete, please contact the sender.
************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20040624/4a449f11/attachment.html>
Received on Thu Jun 24 2004 - 06:50:05 BST
