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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080409/91e889f3/attachment-0002.html>
Received on Wed Apr 09 2008 - 03:32:05 BST
