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

From: John Graybeal <jgraybeal>
Date: Fri, 21 Sep 2012 16:09:45 -0700

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:09:45 BST