[CF-metadata] what standard names are for

[Kenneth Casey]

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