I agree that it's misleading (even to humans, who might not
be as thorough as some software) to use a common standard
name for a quantity that's not actually the measurement of that
observable, as in your example of a temperature anomaly.
The term "derived_quantity" doesn't seem especially helpful as
a standard name modifier, though; many observed phenomena
(salinity, longwave radiation) are, technically, derived quantities.
In our data sets, for "secondary" variables like temperature differences,
we wouldn't usually supply a standard name at all. That's perfectly legit
in CF, and would prevent users from mistakenly using the data as a
"primary" variable, but it doesn't help make the data discoverable.
For that reason, it could be worthwhile to introduce more standard
name modifiers, e.g. anomaly, even if more attributes are needed to
describe the "meaning" of the data.
Regards -
Nan
On 2/25/11 8:56 AM, Schultz, Martin wrote:
> Dear Jonathan,
>
> I don't quite agree with the implication you derive from : "In general, CF metadata describes what a quantity *is* and not how it was calculated from other quantities." -- a temperature difference is a temperature, but you don't want to confuse it with a temperature (pun intended). Suppose you have this wonderful search engine that finds out that NOAA, UK Met Office, JMA, ECMWF and many others provide daily fields of sea surface temperatures. Then you load them all and compute a mean value. What happens if the NOAA values are SST anomalies rather than actual temperatures? As far as I can tell, the software would have no way of telling. OK: you can argue this is why we still need humans, but in my view it defeats the GEOSS concept of interoperability. In particular, because it should be avoidable. But perhaps a simple solution yould be to add a standard_name modifier called "derived_quantity" which would mean that it has similar properties (grid, units, etc.) like the ori
> ginal, but values should not be compared with the original.
>
> Best,
>
> Martin
>
>> It would probably help if we focussed on some real use-cases
>> where it is essential to provide *systematic* metadata i.e.
>> which can be processed by programs. It is always possible to
>> provide descriptive metadata, useful to humans, in
>> non-standardised attributes such as long_name and history,
>> and this can explain how the quantity is obtained.
>>
>> Best wishes
>>
>> Jonathan
>>
>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Fri Feb 25 2011 - 09:58:28 GMT
