[BioSQL-l] ontology for transitive closure table

[Aaron J Mackey]

Well, to be honest, I'm waffling a bit on the store functionality; it
begins to look simply like this:

# fields determined by DBIx::Graph's constructor
my @vert_fields = qw(term_id name definition identifier ontology_id);
my @edge_fields = qw(subject_id predicate_id object_id ontology_id);

# statements either auto-constructed or provided in constructor
my $vert_insert = "INSERT INTO blah blah ?, ?, ?";
my $edge_insert = "INSERT INTO blah blah ?, ?, ?";

# actual store functions:
map {
    my %attr = $graph->attributes($_);
    $vert_insert->execute(
        @attr{@vert_fields}
    )
} $graph->vertices;

my @edges = $graph->edges;
while (@edges) {
    my ($u, $v) = splice(@edges, 0, 2);
    my %attr = $graph->attributes($u, $v);
    $edge_insert->execute(
        @attr{@edge_fields}
    )
}

But then you have the "update" situation, where some of the vertices/edges
may already exist, some won't, others have changed data, etc.  MySQL gives
you REPLACE, otherwise you need to check for pre-existence and then use
UPDATE's instead, it all gets rather hairy rather quickly, and DBIx::Graph
may end up like DBIx::Tree, i.e. "read-only".

-Aaron


On Wed, 19 Mar 2003, Hilmar Lapp wrote:

> If this is meant for storing the whole thing along (which DBIx::Tree
> doesn't do, at least not according to what's documented on CPAN) with
> maintaining the transitive closure table too then I may join you as
> early as next week, as this is more or less exactly what I need here.
>
> 	-hilmar
>
> On Wednesday, March 19, 2003, at 04:26  AM, Aaron J Mackey wrote:
>
> >
> > I'm writing this, with help from ChrisM (I hope), although it's still
> > in
> > planning stages.  But for a very high-level preview, you can take a
> > look
> > at DBIx::Tree to get a flavor for what DBIx::Graph will do (which is:
> > map
> > database tables representing graphs into Graph.pm-like structures and
> > vice versa).  Some not-guaranteed-to-work code:
> >
> > my $dbigraph = new DBIx::Graph @params;
> > my $graph = $dbigraph->graph;
> >
> > my $tc = $graph->transitive_closure; # or whatever Graph.pm calls it,
> > can't remember
> > my $dbitc = new DBIx::Graph @tc_params;
> > $dbitc->graph($tc); # save the tc graph away.
> >
> > where @params and @tc_params define the various tables/keys/whatnot for
> > the relationship and path tables.
> >
> > Of course, Graph.pm has no idea about ontology terms and whatnot; but I
> > believe we'll be able to register callbacks at each "merge" state to
> > qualify the attributes of the edge about to be added to the tc (or deny
> > that the edge should be made at all).  I'm working with the author on
> > this
> > at the moment, but he's a slightly busy guy (Jarkko Hietaneimi of perl
> > 5.8
> > fame, and I'm sure I've butchered his last name).  This is why
> > DBIx::Graph
> > hasn't moved much further beyond planning yet, because I need the
> > hooks in
> > Graph.pm
> >
> > 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?
> >
> > -Aaron
> >
> > On Tue, 18 Mar 2003, Hilmar Lapp wrote:
> >
> >>
> >> On Tuesday, March 18, 2003, at 04:40  AM, Aaron J Mackey wrote:
> >>
> >>> Maintenance of these graphs is left as an exercise to the reader (but
> >>> DBIx::Graph is coming to a CPAN to near you).
> >>
> >> Are you writing this? Is there a preview?
> >>
> >> I'm going to write the RelationshipI adaptor now. I'm wondering
> >> whether
> >> I can take advantage of DBIx::Graph if you're writing this?
> >>
> >> 	-hilmar
> >>
> >
> > --
> >  Aaron J Mackey
> >  Pearson Laboratory
> >  University of Virginia
> >  (434) 924-2821
> >  amackey at virginia.edu
> >
> >
> >
>

-- 
 Aaron J Mackey
 Pearson Laboratory
 University of Virginia
 (434) 924-2821
 amackey at virginia.edu