[CF-metadata] detaching the standard name table

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 23 Jun 2004 19:56:17 +0100

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
Received on Wed Jun 23 2004 - 12:56:17 BST