[GUSDEV] Re: new plugin/CV policy

[Steve F. <sfi...@pc...>]

a clarification:
 
plugins that use CVs fall into two categories:
  1. those that hard code the CV. 
  2. those that do not hard code the CV, but, rather, get it from the input

in case 1, the plugin, obviously, hard codes the CV and does not offer 
the option of a file to change it.

in case 2, the plugin hard codes only a default.  if the user of the 
plugin determines that the input has an different CV, then the user must 
provide a file to the plugin specifying the CV.  (the plugin will fail 
if the input CV does not match the default, or the file if provided)

steve

Steve Fischer wrote:

> folks-
>
> there are a number of "dinky" controlled vocabularies in the GUS schema:
>
> DoTS.BlatAlignmentQuality
> DoTS.GOAssociationInstanceLOE
> DoTS.GeneCategory
> DoTS.GeneInstanceCategory
> DoTS.InteractionType
> DoTS.MotifRejectionReason
> DoTS.ProteinCategory
> DoTS.ProteinInstanceCategory
> DoTS.ProteinProteinCategory
> DoTS.ProteinPropertyType
> DoTS.RNACategory
> DoTS.RNAInstanceCategory
> DoTS.RNARNACategory
> DoTS.RepeatType
> SRes.BibRefType
> SRes.ReviewStatus
>
> These are application specific.
>
> Here is how i think we can manage these.
>
> 1. any foreign key to any of these tables must be nullable
>
> 2. any plugin that writes to or reads from one of these tables must  
> make sure that it contains at least the vocab that the plugin  expects 
> (but possibly a superset).  That is, it reads the table to  make 
> sure.   If the expected vocab is not found, the plugin updates  the 
> table.
>
> 3. the plugin hard-codes a default controlled vocabulary.  It  
> optionally takes a file that specifies the vocab.  This way a site  
> can maintain consistency of the vocab across  plugins and as the  
> vocab evolves.
>
> comments?
>
> steve
>