I don't know if this is supportive or not, but the "sheer number of
groups bringing new requirements" is an issue that I don't think CF
has realistically addressed.
The existing philosophy, "we are getting by OK with our creaky system
so let's stick with it", ignores the fact that some people are not
participating in the system because it is perceived as insufficiently
responsive to their needs.
As a perhaps unrepresentative example, I have 3 different projects
that could bring anything from 10 to 100+ terms each. (And I'm not
talking about the two projects that could bring 1000+ terms.) In
some, the terms are "in use" via other vocabularies (so there is no
way to tell if every term from the other vocabulary is in use). So
rather than just dump a few hundred terms on the list, I've been
waiting for the opportunity to craft a carefully thought out analysis
of clearly useful terms that will only take a few months to work
through the community. The problem is, that time doesn't seem to
come, and meanwhile the mantra is reinforced that small requests are
OK, large ones are not.
I don't think we should have the expectation that CF can be a
completely representative community vocabulary for all data exchange
needs. But I'd like the organizing principals to be clearer so that
it doesn't grind to a stop before its time.
On the other hand, one of CF's strengths would seem to be its
'meaningful identifiers', so I'm not sure if I'd call that the baby or
the bath water, when we're trying to eliminate the unnecessary things.
john
On Oct 20, 2008, at 6:52 AM, 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 <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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Mon Oct 20 2008 - 09:33:56 BST
