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
--
----------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds
Received on Thu Feb 15 2007 - 22:10:48 GMT
