Hi Bryan,
Basically to say - 'seconded'.
I'd also like to point that there's a bigger problem than chemistry waiting in the wings, namely biology. I'm already talking to a group of modellers in an EU project called ECOOP who want to deal in CF with several concentration/chemical expression concepts (e.g. moles as nitrogen, grams as nitrogen, moles as carbon) for various taxonomic groupings. The taxonomy is currently confined to small numbers of high level groups, but I've just heard an ontology for a Harmful Algal Bloom study criticised because it only goes down to the level of genus.....
Cheers, Roy.
>>> Bryan Lawrence <bryan.lawrence at stfc.ac.uk> 10/20/2008 2:52 pm >>>
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 <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
> >>
> >>
> >>
> >>
> >
> >
>
--
Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848;
Web: home.badc.rl.ac.uk/lawrence
--
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 Mon Oct 20 2008 - 09:34:28 BST
