[BioSQL-l] Ontology category

[Matthew Pocock]

I've been thinking about this. One solution is to have a tri-join table 
that equates to the data blob:

Relationship {
   OntologyTerm source,
   OntologyTerm target,
   OntologyTerm relationship
}

These would all be foreign keys into the table that reprents 
OntologyTerm. You could add the pair-wise keys on this table to make it 
quick to pull out everything with a given relationship or all 
source/target pairs for a given source or whatever.

We would need to seed the OntologyTerm table with a few entries that 
give us the ground-rules:
   relation
   equivalent
   one of ( isa : subset )
   one of ( instance_of : member_of )
   one of ( partof : composed_from )
   and, or, not ?
   transiative, reflexive, partial_order, total_order

Once this is set up, we could add a few basic terms for commonly 
encountered collections of terms:
   FeatureType
   cds _instance_of_ FeatureType
   exon _instance_of_ FeatureType
   ...

   FeatureQualifiers

   cds_qualifiers _isa_ FeatureQualifiers

I know basic SQL doesn't give us the transiative closures we need to do 
in-db reasoning over these things, but with these few basic built in 
relations, a spartan basic set of terms and this 3-way join table, we at 
least can represent everything cleanly and provide means for 
domain-specific extentions. I'm sure we can write stoored procedures 
that do the transative closures for us.

Matthew

Hilmar Lapp wrote:
> It appears the Biosql schema is settling down. Among the open spots is 
> what to eventually do with the category of an ontology term.
> 
> The current solution I implemented is ontology terms having a nullable 
> foreign key to themselves that denotes the category.
> 
> There are several things worth mentioning about this.
> 
> 1) First off, it works for us (tm), which means it is fully supported in 
> the TermI adaptor in bioperl-db.
> 
> 2) It is simply modeled after the bioperl object model, where ChrisM and 
> subsequently we had the category slot of Ontology::TermI be another 
> TermI object.
> 
> 3) It has been pointed out by several people that this approach is 
> deficient in that it mixes different entities into one object and 
> potentially cannot capture information one would like to capture about 
> Ontologies (not terms), like namespace, authority, cardinality, type, 
> and whatnot. I agree with basically all of this.
> 
> If the current solution is to be changed, my suggestion is to change the 
> object model first, because otherwise the object model is wrong (worse 
> than the rel. model being wrong), and mapping the same class to two 
> different relational entities is just unnecessary and unjustified 
> complexity.
> 
> Given the fact that it works for us, I'm somewhat lazy to drive that 
> change myself. So I'm trying to solicit concrete proposals here from 
> people who are dissatisfied with the present design. I'm willing to help 
> implementing the winning proposal. To lower your activation energy if 
> the current design puts you off, note that if you don't speak up the 
> current design may end up unmodified in 1.2, which will make it stick 
> for a while.
> 
>     -hilmar
> -- 
> -------------------------------------------------------------
> Hilmar Lapp                            email: lapp at gnf.org
> GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
> -------------------------------------------------------------
> 
> _______________________________________________
> BioSQL-l mailing list
> BioSQL-l@open-bio.org
> http://open-bio.org/mailman/listinfo/biosql-l
> 


-- 
BioJava Consulting LTD - Support and training for BioJava
http://www.biojava.co.uk

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com