Hi all,
I concur with Craig's suggestion, and thanks to John Graybeal for
suggesting sea_surface_foundation_temperature. I suspect many of us
in the SST world are saying to ourselves, "Duh! Now why didn't I
think of that!"
Ken
On Apr 9, 2008, at 5:32 AM, Craig Donlon wrote:
> 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
[NOTE: The opinions expressed in this email are those of the author
alone and do not necessarily reflect official NOAA, Department of
Commerce, or US government policy.]
Kenneth S. Casey, Ph.D.
Acting Technical Director
NOAA National Oceanographic Data Center
1315 East-West Highway
Silver Spring MD 20910
301-713-3272 ext 133
http://www.nodc.noaa.gov/SatelliteData
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080409/f430bcbf/attachment-0002.html>
Received on Wed Apr 09 2008 - 06:18:43 BST
