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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20070216/0def9ab8/attachment-0002.html>
Received on Fri Feb 16 2007 - 09:59:16 GMT
