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
Received on Fri Feb 16 2007 - 14:46:41 GMT
