Re: [Gmod-schema] Re: unique dbxref_id on cvterm

[Chris M. <cj...@fr...>]

On Tue, 22 Feb 2005, Scott Cain wrote:

> On Tue, 2005-02-22 at 08:13 -0800, Chris Mungall wrote:
> > > >
> > > > A cv.name should never be "Ad hoc" because there will be collisions
> > > > between cvs
> > >
> > > Fair enough.  Would you prefer 'local'?
> >
> > Sorry, I was being cryptic. What I meant was, even these "ad hoc"
> > ontologies must have some kind of name that communicates the nature of the
> > cvterms within them. It seemed like you were planning on lumping all
> > ad-hoc ontologies together, which has a high likelihood of producing
> > collisions on cvterm unique keys.
> >
> > It sounds like "Ad hoc:synonym" is actually from a cv of property types
> > that can be attached using featureprop et al. This is very definitely not
> > an ad-hoc ontology, it's crucial that featureprop types have their own cv
> > and are defined
>
> Actually, I only have a few things in 'local'.  They are things that are
> fundamental to making chado work (or the gff loader work), like score
> and synonym.  There are several other ad hoc ontologies that have more

There is nothing gff-specific about the concept of 'score'. There needs to
be an ontology of score types (possibly as part of a larger statistical
term cv). The score column in a gff maps to the most generic score term in
this ontology, since gff doesn't let you distinguish between score types.

Clearly this ontology won't materialize overnight, so I suggest for now
you create an on-the-fly cv called "score" or "program_output", with one
term in it called "score". If anyone is up for it we can create a mini-obo
file with a few more specific terms in it.

> descriptive names like 'property type', and 'Statistical terms'.  I
> think this arrangement makes as much sense as FlyBase chado's use of the
> synonym type ontology with exactly one term in it: synonym.

GO has typed synonyms (exact, narrower_than, etc). All inherit from a
generic "synonym" which corresponds to the cvterm that is in the current
fb chado. I can generate an obo file of synonym types for you if you like.

cvterm is really not intended as a dumping ground for homeless strings.
The whole point of using cvterm for things such as feature types as well
as things like GO is to allow the chado model to be extensible,
interoperable, well-defined etc.

> Darn it, as soon as I wrote that last sentence, I was reminded of how
> it's not true: Lincoln was complaining to me a few months ago about
> WormBase's lack of typed synonyms.  He said it would be nice to have
> 'GenBank synonym', 'Swissprot synonym', etc.  I happily pointed out that
> chado could easily do that.

I'm not sure if I see these as synonym types. We'd want a way to use the
db table here. Can you give an example of a GenBank synonym? Things such
as genbank qualifiers and genbank feature types would go in a genbank cv.

I'm convinced all these so-called ad-hoc CVs can be given homes that will
later mature into full-fledged well-defined stable CVs

> Scott
>
>