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
>
|
