[BioSQL-l] ontology for transitive closure table

[Matthew Pocock]

Use case: I want to be able to use the transitive closure table to cache 
transitive closures, but don't necisarily want to pre-compute them all 
at database-load/edit time. The closures say that we can get from term A 
to term B following relationships of type R by using arcs defined in 
namespaces {X,Y,Z}, which makes the table a 4-tuple. That way, if the 
client looks up transitive closure A,B,R,{I,J} then we know that the 
info isn't in the table, so it needs computing, and possibly caching.

Thomas - are you watching this thread? Any view?

Chris Mungall wrote:
> i seem to be missing the entry point for this thread, not sure what the
> issue is here
> 
> anyway, here are some use cases for different precomputed closures
> 
> [is_a, part_of] - (covering relationships) eg GO style queries
>  eg a searches should traverse all arcs in GO (so long as GO is still just
> is_a and part_of). (In the GOBO relationship ontology, is_a and part_of
> have a supertype of covered_by - this would be the relationship the
> closure would be over)
> 
> [is_a] - SO queries
>  eg, fetching transcripts you want tRNA_transcript etc, but you don't want
> exon which is part of transcript
> 
> [develops_from] - eg in anatmomic anatomies or anything temporal - for
> asking "find anything that happens after X" (got to be careful with cycles
> here - eg does G1 phase happen after M phase?)
> 
> On Tue, 18 Mar 2003, Hilmar Lapp wrote:
> 
> 
>>On Tuesday, March 18, 2003, at 05:27  AM, Matthew Pocock wrote:
>>
>>
>>>If you did the transitive closure calculation considering a set of
>>>namespaces, then I guess you could give a unique ID to that set and
>>>label the path with that set. Thinking about it, that set is much more
>>>sane a label for the path. It says 'I can get from this term to this
>>>term using information only from these domains'.
>>
>>Wouldn't you do this (at least, wouldn't you be able to do this) just
>>as well or even better by depicting the relationship type, as that one
>>inherently is from a domain?
>>
>>In other words, if I define (GO::isa,CORE::isa,CORE::isa) and then
>>asked whether there is a path between two GO terms a and b that
>>satisfies CORE::isa, how is this query going to be resolved? By a SQL
>>query after physically duplicating all GO::isa relationship paths as
>>CORE::isa relationship paths, or by first expanding (in SQL or memory)
>>CORE::isa to all possible (i.e., connected) relationship types and then
>>running the relationship path query for as many rel.types as GO::isa
>>expanded to?
>>
>>The first option IMHO would quickly become unwieldy, a maintenance
>>nightmare, and bug-prone. In the latter option you do not stick (I
>>think) that set label onto anything physically, the set is rather
>>determined by what a chosen relationship type expands to, given your
>>definitions of how relationship types relate to other relationship
>>types.
>>
>>	-hilmar
>>
> 
> 


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