[BioSQL-l] ontology for transitive closure table

[Hilmar Lapp]

On Saturday, March 22, 2003, at 01:17  PM, Aaron J Mackey wrote:

>
> On Wed, 19 Mar 2003, Aaron J Mackey wrote:
>
>> my $dbigraph = new DBIx::Graph @params;
>> my $graph = $dbigraph->graph;
>>
>> my $tc = $graph->transitive_closure; # or whatever Graph.pm calls it, 
>> can't remember
>
> So this bit now works for me (including being able to access all 
> various
> "paths" described by a given transitive closure edge, useful for
> determining predicate type of the new edge).

what is $tc? a reference to an array?

Do you have some place where one can checkout the code? Also, Graph.pm 
has

                $G->has_path($u, $v, ...)

        Return true if the graph $G has the cycle defined by the
        vertices $u, $v, ..., false otherwise.

Didn't this help? Maybe it didn't because you need to enumerate all 
vertices along the path then? (I haven't used that method)

>   But, computing the tc via
> Graph::Directed on GO isa/partof is extraordinarily slow (I've waited 
> more
> than 4 hours now; by comparison, an SQL-only solution finishes in less
> than 20 minutes).

How do you deal with paths that have heterogeneous predicates, i.e., 
both is-a and part-of? In Singapore we defined that the predicate of 
the path is the GCD, but there is no common denominator defined yet for 
those two predicates. Did you define one behind the scenes (like 
related-to)?

>
>> Slightly OT, but if I were to implement our own Graph.pm-like object 
>> via
>> an Inline::C-wrapped graph library, would people be keen on that?
>
> I'll ask again - I need to be able to calculate tc graphs in a 
> reasonable
> amount of time; are people willing to go through the extra hassle of
> installing bioperl-ext to get faster Graph functionality?
>

The problem is its more a hassle for you than for people, because if 
someone can't compile the code on his specific platform, or hits a 
dynlink error, or hits a segfault, then most likely it is going to be 
you chasing down subtle allocation/de-allocation bugs, or stupid 
OS/perl version differences or whatever. Whereas with pure perl, if it 
compiles under 5.6.1 on your OS, perl kind of promises to you it will 
also compile under WierdoOS, provided perl itself does, and supposedly 
it will collect the garbage too.

So, if I can just say 'cpan> install Aaron::XS::TC' and then it will 
install, there's not much hassle there for me. However, what if I'm on 
Windows or wherever, and the above fails, what will you do as the 
maintainer? Likewise, you test drive your code on SOFA with a couple 
hundred terms and all is fine, but I have my own proprietary ontology 
with 15000 terms and your code segfaults on this after having taken 2.5 
GB of memory on an OS you have no access to - what are you going to do 
then?

	-hilmar


> -Aaron
>
> _______________________________________________
> BioSQL-l mailing list
> BioSQL-l at open-bio.org
> http://open-bio.org/mailman/listinfo/biosql-l
>
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------