Hi Bryan,
I agree with your summary of the problem. But less clear about the
solution. Can you put some more meat on the bone of your proposal to
"introduce hierarchy earlier in the process". In terms of human effort,
I presume that you are envisioning this as a way to make the problem
more scalable; to get more individuals working in parallel. (Apologies
if this was already spelled out in an earlier message. Just point me to
the email archive, if so.)
- Steve
===================================
Bryan Lawrence wrote:
Hi Folks
I'm going to reply to this, rather than put my name against a prediction of
number of chemical species :-) :-) Warning. This is rambly and doesn't go
anywhere. But I wanted to say it anyway. You can read it or not!
What we have now is a set of "meaningful identifiers" which we call "standard names" that map onto definitions which accurately describe quantities (and units).
It so happens we have a method of constructing our meaningful identifiers that
is creaking at the seams - we all moan about how long it takes to get a
standard name through the system, and that's with two people working lots of
hours on it, one of whom does it in the dead of night (he must do, because he
has a day job as well, and I've seen some of his email times :-).
The list of these identifiers is already long, and the solution Steve suggests
("let's produce an ontology") is a good one. It has my whole hearted support,
but it doesn't address the issue of long term development of new standard names, and it
does imply that that the identifier eventually becomes less important than the
relationships and the definitions (and an abbreviation for that definition, which we
might get from the common concept).
Common concept addresses quite a lot of concerns (me, I think it's rather more
than a small sub-community, but I don't mind the description :-), but it
doesn't address them all.
I do think Chemistry is going to make life difficult, but as I tried to imply,
just the shear number of new groups bringing new requirements is going to break
this endeavour if we carry on. CCMVal I think was rather typical, they came to
use with a lot of new names, and wanted them handled quickly. Well, we managed
just about, but what if we had two or three groups at once (as I fully expect
next year)?
So what I think is that if we carry on investing all our effort in agreeing the "meaningful
identifier" instead of agreeing on the "definition it points to", CF will eventually
grind to a stop ... which leads me to trying to introduce hierarchy earlier in the process,
allowing us to abstract away some of the agony and spend time concentrating on a smaller part of
the problem each time. I'm sure that'll be the way to go with chemistry, and in the longer run, for
CF standard names in general. Common concept will help with some of this, but not all.
Cheers
Bryan
On Friday 10 October 2008 22:25:53 Steve Hankin wrote:
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 <[EMAIL PROTECTED]> 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@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Steve Hankin, NOAA/PMEL -- [EMAIL PROTECTED]
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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata