⇐ ⇒

[CF-metadata] detaching the standard name table

From: Jonathan Gregory <j.m.gregory>
Date: Fri, 25 Jun 2004 19:27:15 +0100

Dear Bryan et al.

Several people have said that we don't want proliferation to allow tables to
overlap, giving alternative choices of names. If that happens, it will defeat
the purpose of standard names. If we split up authority into domains which are
separately managed, there will be such problems at the interface (e.g. the
fluxes between the ocean and atmosphere will be given different names in the
two domains). No-one has suggested how we will prevent this happening. Bryan
writes, "Projects should try very hard to identify synonyms in other tables,
but I think it will be an SEP (Somebody Elses Problem) to work on ontological
mappings between these tables." I think that means, in practice, no-one will
take responsibility for it and it will not be done.

Bryan also writes, "If the standard names are to become more widely used than
amongst the climate modelling community there has to be a visible mechanism by
which those wider communities can influence (even control) the name evolution
... A mechanism to achieve that would be to spawn a new mailing list, to which
anyone interested could subscribe. New name proposals could be discussed there
and possibly voted on." I wish that would happen, but I don't understand in
what sense the current arrangement is not visible! We already have a mailing
list. People have been invited to vote. Even in the domain on which most of the
current subscribers are knowledgeable, very few people vote or express an
opinion about the right choices to make. The majority presumably assume it's
someone else's problem. Why should the situation be any different if we had a
new mailing list?

I think that is a difficult task to identify and properly describe the
quantities we want to name. My question is, Whose reponsibility will it be to
do that thinking? Changing the arrangements will not make the need go away.

Cheers

Jonathan
Received on Fri Jun 25 2004 - 12:27:15 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒