[CF-metadata] Another potentially useful extension to the standard_name table

From: Cameron-smith, Philip <cameronsmith1>
Date: Fri, 21 Sep 2012 16:24:56 -0700

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
Received on Fri Sep 21 2012 - 17:24:56 BST