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

[Luis Bermudez]

Steve et. al.

I have been thinking about this issue for awhile. I have put my  
thoughts here: http://marinemetadata.org/wlusp. Hope this can help to  
eventually put boundaries and constraints when defining CF variables.

-Luis


Luis Bermudez Ph.D.
MMI Technical Lead - http://marinemetadata.org
bermudez at mbari.org Tel:  (831) 775-1929
MBARI 7700 Sandholdt Road, Moss Landing CA 95039-9644, USA





On Feb 16, 2007, at 8:59 AM, Steve Hankin wrote:

> Agree with your point, John.  Defining the boundary -- what level  
> of semantics is appropriate to capture in the standard name -- is a  
> basic question to answer.  (Has it already been answered,  
> somewhere?)  It would provide a guideline for this sort of question.
>
>     - Steve
>
> John Graybeal wrote:
>> At 5:57 PM -0800 2/15/07, Steve Hankin wrote:
>>> That seems to defeat our intent that the semantics of CF  
>>> variables are captured in the standard names for easy usage by  
>>> clients.
>> Adding to that question, I have been wondering if it is clear to  
>> the principles that *all* the semantics of CF variables can be  
>> captured in the standard names? At some point does the complexity  
>> of the name make the parsing problem too heavyweight? John (who's  
>> read the thread for 2 months now, but the answer likely came  
>> before that...) At 5:57 PM -0800 2/15/07, Steve Hankin wrote:
>>> 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 _______________________________________________ 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata