Roy, Bryan, Jonathan,
Since my name has been entered into the discussion (and not accompanied
by a 4 letter word ... how remarkable :-P ), I'll add 2 cents.
CommonConcept is potentially a tidy solution for tying together a small
sub-community, and in that sense it may provide a valuable escape valve
for the "deluge of MIPS" (Bryan's concern). But it is not an answer to
broad semantic interoperability. In fact it seems more likely to be a
step backwards in that regard -- echoing Roy's concern, below.
Jonathan's point seems valid, that splitting up the namespace into areas
which develop separately is a formula that can lead over time to
inconsistencies. In any case, CF already has a single long list of
names. There have been dozens (hundreds?) of opportunities to subdivide
the list that were bypassed. We have a self-consistent approach now,
for all that it (like any solution) has some warts.
(There. I've managed to agree with all 3 of you. :-) What are the odds
of a 4-body collision?)
So how to resolve the scaling problems we are alluding to? I believe
that the answer is to develop an ontology (in as simple a form as
possible) that explains how the names in the list are semantically
related to one another. At the GO-ESSP meeting Roy and I discussed that
such a mapping might be embedded into his vocabulary server (and see
where that leads us). The idea is that humans and machines have a need
to identify closely related variables that is almost as strong as the
need to identify exact matches. If a human or software is looking for
the temperature of the sea surface, they should be aware of the
semantically related standard variables
|sea_surface_foundation_temperature
||sea_surface_skin_temperature
||sea_surface_subskin_temperature
||sea_surface_temperature
||sea_water_temperature
etc.
|
||I recall that Roy volunteered to experiment with this as a volunteer
action item at the end of the meeting. (I still owe the GO-ESSP group a
cleaned up version of that action list). I think over the long term we
are going to come to depend very heavily on such a resource. Immediate
example of this was the visual "full table scan" of the CF list that I
had to do 3 minutes ago in order to find the variants of sea surface
temperature just above.
- Steve
||
============================
> Roy Lowry wrote:
>
>> Hello Heinke,
>>
>> In principle, this is a good way to go and is a step to basing Standard Names on a semantic model, which Steve Hankin has been advocating for a while. The concern from my perspective is that I want to interoperate semantically with CF files - for example automatically generating an ISO19115 record from a directory full of CF. To do this with the physical and chemical components of the Standard Name I need a mechanism to tell me where both components are. As you rightly say, the 'common concept' would do the job.
>>
>> Consequently, I see 'common concepts' as a blocker to our being able to decouple Standard Names into physical and chemical components. I also see Ticket 29 - the formalisation syntax for describing a common concept - as the blocker to 'common concepts'. Taking ticket 29 forward has been on my 'todo' list for far too long and I'm currently acquiring work faster than I'm clearing it. Is there anybody else willing to take a lead on this?
>>
>> Cheers, Roy.
>>
>>
>>
>>>>> Heinke Hoeck <heinke.hoeck at zmaw.de> 10/10/2008 8:02 am >>>
>>>>>
>>>>>
>> Dear all,
>>
>> Martina Stockhause wrote:
>>
>>
>>> I apologize for this long list. My idea to move the name of the chemical
>>> constituent or aerosol from the standard name into an attribute was dismissed
>>> by the scientists. The disadvantage of a CF standard name without the
>>> constituent was larger than the advantage of a smaller number of CF standard
>>> names to be proposed.
>>>
>>>
>>>
>>>
>> I think it was a good idea to move the constituent into an attribute. If
>> we allow the
>> combination of physical quantity with the chemical constituent or
>> aerosol to construct
>> the cf standard name we will generate a very long list of new
>> cf-standard names (thousents).
>>
>> The splitting could be done like the area_fraction with a coordinate
>> variable or scalar coordinate variable.
>> The list of allowed chemical constituent or aerosol should be limited.
>>
>> I like to give an example (I don't know the IUPAC list, if 'ozone' is
>> not right, please correct it):
>>
>> dimensions:
>> lat=72;
>> lon=124;
>> maxlen=30;
>> float quantity(lat,lon,height,time) ;
>> quantity:standard_name = "mass_fraction_of_constituent_in_air" ;
>> quantity:units = "1" ;
>> quantity:coordinates = "constituent" ;
>> char constituent(maxlen);
>> constituent:standard_name='IUPAC_system';
>> data:
>> constituent='ozone';
>>
>> The list of valid constituent or aerosol could be SMILES, IUPAC or CAS.
>> Or the CF community build up
>> such list.
>>
>> This is the same system Martin Suttie uses with the two tables. One
>> table with the physical
>> quantity would be the CF standard name and the second table would be the
>> variable with the
>> chemical constituents and aerosols.
>>
>> If the community need the combination of both in one name in the header
>> the common concept
>> could be the solution. See track #24. But this is in work.
>>
>> For example:
>> x:common_concept_urn = "urn:cf-cc:grib123";
>> x:common_concept_local = "{grib2.wmo}mass_fraction_of_ozone_in_air";
>>
>> As a source to construct chemical cf standard name and to build up a
>> list of chemical constituent or aerosol
>> I like to propose:
>> http://wiki.esipfed.org/index.php/CF_Standard_Names_-_Construction_of_Atmospheric_Chemistry_and_Aerosol_Terms
>> It need an update but the I like the structure.
>>
>> Best regards
>> Heinke
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.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
"The only thing necessary for the triumph of evil is for good men
to do nothing." -- Edmund Burke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20081010/0a9e1ba7/attachment-0002.html>
Received on Fri Oct 10 2008 - 15:25:53 BST
