[CF-metadata] what standard names are for

Wed Apr 9 08:53:18 MDT 2008

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.html 