Hi All,
I agree with Ken and Craig.
Dave
On 9 Apr 2008, at 13:18, Kenneth Casey wrote:
> 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/edfd17da/attachment-0002.html>
Received on Wed Apr 09 2008 - 08:53:18 BST
