Hello Everyone:
The thread on SST names has diversified to a wider discussion and I wanted
to return to my immediate problem which is to help establish functional SST
names for a functional community already committed to and using netCDF.
A few observations: The process is very long winded and I'm wondering about
the benefit. The names that have been proposed originally are those agreed
by a wide international community working on both research and operational
centres including climate and real time systems. They seem quite happy with
the names and their definitions they agrereed upon (the definitions
published some years ago in a Journal of Climate paper). This community
moves ~25Gb of SST data about each day using these names and we have no
complaints about our CF names from the user community.
The CF-metadata list community is a very small gatekeeping one that is
trying to control CF names proposed by communities like GHRSST-PP. The
deate is interesting in some ways but so far the outcome for me is confusion
and chaotic. Baserd oin this group, there is a need for me to return to the
entire GHRSST community and ask them to change all thier standard names
(which they were agreed in some heated debate). We also have to consider
retrospective reprocessing all data sets to conform to the new names. Who
will pay now to do this? and where is the evidence in the dicussion on
CF-metadata that this is truly required? With all respect Johnathan, I
realise that you have some issues with foundation and prefer diurnal as a
nicer description but the truth of the matter is that the definitions
proposed are published definitions and ones established by a large
community representing the variabile in question. Why should they change
based on a small debate like this? /i'm sure that there are many other
examples that are poorly understood byu a person off the street but this is
to be expected as these are complex issues. We are here to serve the needs
of a Scintific community that is intelligent and I thisnk that CF-metadata
should devote more time to making sure that functional linkages between peer
reviewd papers and the definitions they are controlling is established and
maintained rather than off the top of the head discussions.
There are some serious issues for you all to think about when debating the
cases that have been presented to you by long standing international experts
in their fields representing large user communities. The net result so far
from the CF-metadata discussion from my perspective is a difficult taks of
convincing my community that the changes CF-metadata have authorised are
worth implementing and convincing agencies to now stump up considerable
amounts of cash to pay for all of this. I suspect it will take some time
and some may choose to ignore the CF convention if this kind of thisng
continues. I think that CF-metadata is here to help the authoritative
communities and I'm not sure that in the SST case this has happened with any
efficiency.
Sorry for the divergence here but it is something for you to think about.
Returning now to progress towards a conclusion. I attach my summary mail
before the SST thread diverged and would like to obtain some consensus to
help Alison progress with the final tables. Please can you provide your
comments and lets move forward or I propose to give up and stop.
Regards
Craig
2008/4/9 Craig Donlon <craig.donlon at gmail.com>:
> Hi all:
> Just to recap on the logical 'family' of SST names we have currently on
> the table (definitions are well described in Alisons last mail):
>
> surface_temperature
> sea_water_temperature (at depth)
> sea_skin_temperature
> sea_subskin_temperature
> sea_foundation_temperature
>
> and a proposal for
> sea_surface_foundation_temperature
>
> I believe we are going in full circle now and I would like to consider the
> sea_surface_temperature 'family' and return to
>
> surface_temperature (already defined)
> sea_water_temperature (for temperatures at depth)
> sea_surface_skin_temperature
> sea_surface_subskin_temperature
> sea_surface_foundation_temperature
>
> I feel that this solution clearly defines our scope (the sea surface),
> delineates the character of the data (skin, subskin, and foundation) and
> defines the data as temperature. Also, there is a logic to the family.
>
> Best regards,
> Craig
>
>
>
>
> 2008/4/9 Bryan Lawrence <b.n.lawrence at rl.ac.uk>:
>
> On Tuesday 08 April 2008 22:30:32 John Graybeal wrote:
> > > Some observations:
> > >
> > > A term that is accepted in a science domain, but is likely to conflict
> > with
> > > understood meaning in another science domain or in a non-scientific
> > > context, probably should not be accepted on the 'current usage trumps
> > > future usage' principle. Foreseeable areas of likely confusion should
> > be
> > > avoided.
> >
> > I don't disagree with that, where the future usage is predictable. But
> > if 'ts
> > just possible (and not probable) then I would.
> >
> > > Further, areas of likely confusion should not be addressed on the
> > basis of
> > > "the term name connotes something else, but at least the definition is
> > > clear." A false connotation is harmful to use of the vocabulary.
> >
> > I don't disagree with that, but removing clarity from the primary usage
> > doesn't add value either.
> >
> > > At the same time, if a term does become ambiguous due to additional,
> > > overlaid, or replaced meanings, a synonym could be added that could
> > > eventually supplant the original use. It is important to have this
> > option,
> > > so we're not totally locked in to outdated terms.
> >
> > One of the reasons why I'd rather have opaque identifiers! Then the
> > primary
> > identifier is immutable, and one can have evolution of appropriate
> > terms.
> > (But, to anticipate Jonathan, opaque identifiers without easily usable
> > resolvers are useless).
> >
> > > If a particular name is confusing because its meaning is opaque to the
> > lay
> > > data management community, that is not as big an issue. It is then
> > > essentially a code to those outsiders, to be looked up if necessary.
> > > Whether advanced or localized scientific usage should be promoted into
> > wide
> > > usage (thereby becoming less code-like), or eschewed in favor of more
> > > generally understandable terms, is the typical 'mindshare' tradeoff.
> >
> > For whom do we write cf-netcdf files? In most cases for ourselves and
> > our
> > existing community. I would argue that much of the effort to make CF
> > names
> > self-describing beyond the primary user community is mixing up different
> > classes of the metadata taxonomy. I can elaborate on that add nauseum
> > at a
> > later date.
> >
> > > A specific reaction, then, from someone who is an outsider to the
> > community
> > > and the science in question:
> > >
> > > The term 'sea_foundation_temperature' bugs me, because it appears to
> > mean
> > > something (the foundation of the sea) that it does not actually mean,
> > and
> > > that someday may be important in its own right.
> >
> > Now that's an important point.
> >
> > > Suggestion:
> > >
> > > On the other hand, the term 'sea_surface_foundation_temperature' is
> > totally
> > > transparent in that regard -- I understand that is not the foundation
> > of
> > > the sea, and even though I don't know exactly what it is, I can look
> > it up.
> > > It's even clearer to me than
> > > sea_surface_temperature_at_diurnal_thermocline_base, for whatever
> > that's
> > > worth.
> >
> > I agree, it's more clear to me.
> >
> > > Interestingly, I don't believe sea_surface_foundation_temperature has
> > been
> > > suggested in this thread, at least in its recent incarnation.
> >
> > Would it be acceptable to the primary user community?
> >
> > Bryan
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
>
>
>
> --
> Dr Craig Donlon
> Director of the International GODAE SST Pilot Project Office
> Met Office Hadley Centre,
> Fitzroy Road, Exeter, EX1 3PB United Kingdom
>
> Tel: +44 (0)1392 886622 Mob:07920 235750
> Fax:+44 (0)1392 885681
> Skype ID:crazit
> SkypeIn: +44 0141 416 0882
> E-mail: craig.donlon at gmail.com
> http://www.ghrsst-pp.org
>
--
Dr Craig Donlon
Director of the International GODAE SST Pilot Project Office
Met Office Hadley Centre,
Fitzroy Road, Exeter, EX1 3PB United Kingdom
Tel: +44 (0)1392 886622 Mob:07920 235750
Fax:+44 (0)1392 885681
Skype ID:crazit
SkypeIn: +44 0141 416 0882
E-mail: craig.donlon at gmail.com
http://www.ghrsst-pp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080412/13f10d0f/attachment-0002.html>
Received on Sat Apr 12 2008 - 03:17:01 BST
