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.
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.
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.
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.
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.
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.
Interestingly, I don't believe sea_surface_foundation_temperature has been suggested in this thread, at least in its recent incarnation.
John
At 9:38 PM +0100 4/8/08, Jonathan Gregory wrote:
>Dear Bryan
>
>I'm replying in a different thread so as not to confuse the one on SST names.
>
>> There is no
>> question in my mind that if a large community already uses a specific
>> vocabulary term, then as long as it is reasonable (in some sense to be
>> agreed) and doesn't CONFLICT with other usage, our default position should be
>> to use that vocabulary identifier, but make damn sure the definition
>> encompasses all possible users ... (as opposed to the name itself satisfying
>> all possible users).
>...
>> I would argue for sea_foundation_temperature on the fact
>> that usage should trump possible futures (which is one of the key tenets of
>> CF).
>
>I suppose it does depend on what you mean by "reasonable" :-). I agree that
>what is required now is a more important consideration than future needs; yes,
>that is one of our principles. But another one is that CF metadata should be
>self-describing. I think that standard names are something between technical
>terms, and the definitions of those terms. I don't think it is sufficient for
>a term to be in use for it to be adopted as a standard name, even if it does
>not conflict, because it may not be self-explanatory to the wider community of
>people who might use the dataset. Of course, the users could always look up the
>definitions, but they might not know where to find them, or they might be lazy.
>We should minimise the need to look things up. That's a reason for not using
>codes (like GRIB codes), that likewise depend on external definitions in order
>to be understood.
>
>Best wishes
>
>Jonathan
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
----------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds
Received on Tue Apr 08 2008 - 15:30:32 BST
