Hi Dave:
Thanks for the comments. We can always use an attribute to describe the
estimated depth of the foundation temperature. But, just as for the Mixed
layer depth, you must specify which method is used to define the MLD. In
our case, we are looking at the sea surface with reference to a diurnal
thermocline which is in the sea surface layer. Compared to bulk SST (which
could be anything in the top 20m in my experience, we are making progress.
Take care
Craig
2008/4/9 David Poulter <d.j.s.poulter at soton.ac.uk>:
> Hi All,
>
> I'm going to throw in my thoughts at this point, but I'm only going to
> address the last question here. Speaking on behalf of the community
> (sorry for those who missed my election to this lofty office!!) I
> think the term 'sea_surface_foundation_temperature' is perfectly
> acceptable, and in fact possibly even more so than
> 'sea_foundation_temperature'.
>
> It is important t note however, that there is no guarantee that the
> 'foundation temperature' will physically occur anywhere near the
> surface. If one where to take a thermometer and descend through the
> water until one found the 'foundation' temperature, one would be
> floating at a different depth everyday. Does this make the inclusion
> of the word 'surface' dishonest? I do not think so... but I guess it
> depends on what the definition of 'surface' is!!!
>
> The community tend to use the phrase 'foundation temperature', instead
> of 'foundation SST' for this exact reason. SST implies a known depth
> (intuitively zero!), but we know the 'foundation depth', that is the
> depth of the 'foundation temperature' is dynamic. For this reason, I
> am starting to think that 'sea_foundation_temperature' is perhaps a
> little more, perhaps honest is the word?
>
> However, I think in reality both are perfectly acceptable!
>
> I hope I haven't confused anyone!
>
> Dave
>
> P.S. Apologies for not responding earlier, I have been away for a while!
>
> David J. S. Poulter, SST Scientist
> National Oceanography Centre, Southampton
> European Way, Southampton, SO14 3ZH, UK
> Tel: +44 (0)23 80596107
> E-mail: djsp at soton.ac.uk http://www.hrdds.net
>
>
>
> On 9 Apr 2008, at 07:40, Bryan Lawrence wrote:
>
> > 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/29f85fd5/attachment-0002.html>
Received on Wed Apr 09 2008 - 08:12:37 BST
