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 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
