Hi Steve,
A point that has occurred to me many times. It really comes down to a legacy problem from days when systems set data models in concrete. The only flexibility was through vocabularies so more and more semantics got loaded into terms. The BODC Parameter Usage Vocabulary is a case in point where all manner of information, such as methodology, has been hung off a single key. I'm trying to reverse this process by replacing the text term hung off the key with a data model - which I'm still slowly progressing - to separate out all the semantic elements that had been thrown in together.
The advantage of this approach of dealing with semantically simple elements - to take Jonathan's example of"air" and "temperature" rather than "air_temperature" is twofold. First, the simpler the semantics the easier it is to introduce semantic interoperability through mapping. Secondly, better navigation systems can be built on hierarchies compared to flat terms. For example, on reaching 'air' a system could then offer the options 'temperature', 'pressure' and whatever else is available associated with 'air'.
Cheers, Roy.
>>> Steve Hankin <Steven.C.Hankin at noaa.gov> 2/16/2007 4:59 pm >>>
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
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Fri Feb 16 2007 - 10:20:16 GMT
