I think Roy's subsequent emails have correctly seized the essence of my first comment.
MMI is a colloquial term (sorry) for the vocabulary service run by the Marine Metadata Interoperability project, at mmisw.org. Its services are accessed from anywhere, the vocabularies are stored at the server. Vocabularies modifications are limited to the author, at the moment anyway.
Complete integration of the resulting vocabularies (wherever they live -- MMI was simply one example) into CF tools could call for additional development, but the integrated services would provide a nicely unified capability.
John
On Sep 21, 2012, at 16:24, Cameron-smith, Philip wrote:
> Hi John,
>
> Jonathan's program already generated the vocab from the existing names (hopefully we can prevail on Jonathan to run it on the latest CF version). That should seed the program(s). Vocab could then be added as desired.
>
> For the program to have staying power, it will be necessary that the grammar also be easy to amend and extend.
>
> What is MMI?
> Would it be run locally, or via the web, or both?
>
> Best wishes,
>
> Philip
>
>
> -----------------------------------------------------------------------
> Dr Philip Cameron-Smith, pjc at llnl.gov, Lawrence Livermore National Lab.
> -----------------------------------------------------------------------
>
>
>
>> -----Original Message-----
>> From: John Graybeal [mailto:jgraybeal at ucsd.edu]
>> Sent: Friday, September 21, 2012 4:10 PM
>> To: Cameron-smith, Philip
>> Cc: Jonathan Gregory; cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] Another potentially useful extension to the
>> standard_name table
>>
>> I like this.
>>
>> I may be a step behind, but given a grammar parser/generator, we will have
>> identified the slots. But we will not have identified all the terms that can fill
>> those slots.
>>
>> I don't think this is a huge challenge. We will have (a) a list of terms already
>> filling those slots, (b) candidate vocabularies that we could mine -- or designate -
>> - or create -- to supply additional terms. I would be delighted to participate in
>> construction the list of terms and vocabularies. (Especially if you let me use
>> MMI to store them. Wink wink nudge nudge. :->)
>>
>> Anyway, please correct me if I'm missing the boat, or tell me if there's already a
>> plan.
>>
>> John
>>
>> On Sep 21, 2012, at 15:52, Cameron-smith, Philip wrote:
>>
>>> Hi All,
>>>
>>> I am just catching up on the backlog of CF emails. My sense too is that this
>> discussion is trying to solve the problems caused by a lack of grammar with
>> alternatives and/or stopgaps. My preference is to overcome the
>> grammar/vocab challenge, but I am well aware that an accepted solution has
>> not yet occurred.
>>>
>>> In order to get us on the right track, I propose we take advantage of
>> Jonathan's suggestion in a way that doesn't require a full grammar/vocab
>> definition, and doesn't require any changes to the controlling CF documents.
>>>
>>> Specifically, I propose the following:
>>>
>>> 1) We leverage Jonathan's grammar program into (a) a program that checks a
>> proposed std_name by parsing it to see whether it fits existing grammar/vocab
>> rules, and/or (b) a std_name generation program.
>>>
>>> 2) Std_names are still proposed in the ordinary way, but if they have passed
>> the checker or been created through the generator then it will be easy for
>> people to accept them. We might even move to a mode in which pre-approved
>> std_names are automatically accepted after a month, unless someone objects.
>>>
>>> This has several advantages:
>>>
>>> A) It will reduce time and effort by everyone to get std_names approved.
>>> B) Neither the parser nor the generator needs to be complete (ie, it is OK if
>> some existing names don't comply, or there are some valid new cases they don't
>> cover)
>>> C) Proposals that don't fit the standard construction can still be approved, and
>> will highlight ways to complete and extend the parser/generator.
>>> D) Any mistakes by the parser/generator should be caught by the email list.
>>>
>>> I see no disadvantages other than the need for someone to create the parser
>> and/or generator, which should be technically straightforward.
>>>
>>> Best wishes,
>>>
>>> Philip
>
----------------
John Graybeal <mailto:jgraybeal at ucsd.edu> phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Sat Sep 22 2012 - 16:26:52 BST
