⇐ ⇒

[CF-metadata] CF and a representation of probalistic forecasts

From: Steve Hankin <Steven.C.Hankin>
Date: Thu, 15 Feb 2007 17:57:01 -0800

All,

Generalizing from this discussion ...

Where do we stand on the larger question of multi-level approach to
standard naming? The question that has been posed is about
"overloading" standard names -- using the same standard name for
distinct variables (possibly within a single CF dataset), where some
other attribute of the variable (cell_methods, long_name, or maybe the
name of the variable, itself) is used to sort out the distinctions. We
have a measure of inconsistency already in how we handle these second
order distinctions. As examples we also have families of standard names
based upon "...transport_due_to ...", "...thickness_defined_by_...",
and "...tendency_of_..._due_to_...". This latter approach might
suggest adding a family of names "realization_weight_based_upon_...".

But future software that tries to work with standard names is going to
find itself parsing our current names to discover the underlying
families and sifting through other attributes to understand the deeper
semantics. That seems to defeat our intent that the semantics of CF
variables are captured in the standard names for easy usage by
clients. In my opinion, these overloading techniques taken
collectively seem to be crying out for a more general, multi-level
naming solution.

    - Steve

P.S. We also have "product_of_..." variables, which points to the need
for another level of naming that is above, rather than below the
fundamental quantities.

Disclaimer: As per usual, I confess to jumping into the conversation
without a full and thorough reread of the entire thread and its
antecedents. I hope you'll be forgiving. :-[

========================================

Jonathan Gregory wrote:
> Dear all
>
> Bryan asked "How is that different from differing methods of cell methods with
> the same standard names?" That's a good question: I suppose I'd say that we
> would use the same cell_methods entry to indicate a mean, for instance,
> regardless of how it had been weighted. At the moment we can only record that
> by a non-standardised comment in cell_methods such as "(area-weighted)". But
> quantities which could be used for weights in this situation might be in data
> variables and could be distinguished by standard names, for instance cell_area
> or land_area_fraction. I think the realization weights are more analogous to
> those quantities than they are to different cell methods.
>
> I agree with Steve that the realization weights are a bit like masks. I think
> CF would distinguish between mask quantities by standard names too, though at
> present the only one we have in the table is land_binary_mask.
>
> Jamie remarked, "I think the weights are the same kind of quantity even if they
> are calculated different ways - just as air_temperature is considered the
> same quantity even if calculated from a GFDL model or a ECMWF model." That
> might be the case, I suppose; two sets of weights might simply be alternative
> values for the same quantity. If they came from different models that could be
> indicated in other ways (as in the ensembles discussion). I'm not sure of what
> examples to use - perhaps you could suggest some - but maybe you might have
> weights that were based on the realism of historical temperature simulation
> for instance, or on a measure of quality of present-day mean climatology. The
> quantities being used for assessment could have standard names, and they would
> be different names. Hence so should weights based on them, I suggest.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>

-- 
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
Received on Thu Feb 15 2007 - 18:57:01 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒