[Bioperl-l] First commit of Bio::Structure objects

[Kris Boulez]

Quoting Corradi, John (John.Corradi@astrazeneca.com):
> 
> 
[ ... ]
> > 
> > What about my other solution, have a Protein object, the 
> > protein stores a
> > graph of all parent child relationships, so the 
> > ProteinComponent objects
> > know nothing of their parents/children.
> > 
> > ie instead of 
> > 
> > $atom->get_residue()
> > $residue->get_atoms()
> > 
> > you would so 
> > 
> > $protein->get_residue($atom)
> > $protein->get_atom($residue)
> > 
> > This is effectively the same as Ewan's solution, it's just 
> > that you give
> > the scriptwriters a hand with the bookkeeping, inside the 
> > protein object.
> > The user could eschew the protein object and do their own 
> > bookkeeping via
> > ids.
> > 
> > there could either be one protein object per protein, or a singleton
> > object that stores all protein component graphs (the latter would be
> > useful if anyone ever wanted to add protein-protein 
> > interaction stuff to
> > bioperl)
> 
> I'm coming into this late and I don't know all the specific issues relevant
> to this model.  However, Chris' suggestion is the route we took when we
> implemented a Gene Ontology browser at Jax.  A graph object keeps track of
> nodes and edges so the nodes don't need to know about their parents or
> children.  Likewise, the graph doesn't need to know much about the nodes
> (perhaps only that a node has a unique id).  Don't know if ours was the
> cleanest design, but it avoids the bidirectional links that are making heads
> hurt.
> 
OK, I see the need/elegance of a design which has the graph layout of
the objects in the top object. Although I'm still dissapointed in Perl
not being able to deal with the (simple) layout of my original objects.

The graph object you describe, is this available somewhere ? I looked at
http://www.informatics.jax.org/go/ (which I think is the GO browser you
are referrig to), but could find no link to source code.

On CPAN I found a Graph package (Graph-0.201), which seems pretty
complete at first sight. It does require an other external package
(Heap). Thus adding two more external packages one needs to install to
get BioPerl running.

Another option might be to do something pretty basic ourselves. Storing the
child-parent relations in a hash ( $c_p{$child} = $parent ) and the
parent-child relations in a hash to array refs 
( $p_c{$parent} = \@children ). It looks basic, but workable to me.


We (my collegues and I) still think that having methods like

$atom->residue
$residue->chain
$chain->residue

would make working with the objects more natural. To accomplish this we
only need a reference from every child object (at whatever layer) to the
grand parent ('holder object' in Ewan speak). Thus allowing the residue
method in Atom (first example) to translate the call to

$self->_grand_parent->get_residue($atom) 

The only thing that is needed is a DESTROY method on the grand parent 
which deletes the graph(s), thus breaking all circular refs.


Kris,