[Biopython-dev] Pathway Module

Tarjei S Mikkelsen tarjei at genome.wi.mit.edu
Wed Aug 1 23:49:33 EDT 2001

>  > > Step is separate from reaction, because a reaction could occur in
> > > more than one pathway.
> >
> > I'm not sure I see the rationale for this. It is true that a reaction
> > can occur in several pathways, but unless there is information about a
> > reaction that only applies to a specific pathway there is no need to
> > keep a separate Step object - you can just let two different pathway
> > objects reference the same reaction object.
> >
>    The information that applies to just one pathway is the branching and
> sequence, the in links and out links to other steps..  Maybe you can tease
> this information out of the products and substrates for each
> reaction, but I
> thought of using explicit links from one step to the next step(s).

 So there are two issues here: 1) When is there a link between two
reactions in a pathway? and 2) How do we represent those links?

 For 1) my understanding is that a pathway is uniquely defined by the
substrates and products of its constituent reactions. That is,
there is always a link from A->B to B->A and from C + D -> E to E -> F,
and there is never a link from B->A to A->B, or from E -> C + D to A -> B.
Because of this I think it is important that a Pathway/System class
infer links between reactions automatically. That is, if a user
combines two reactions A -> B and B -> C into a pathway, s/he should
not have to explicitly define the link between them.

 For 2) there are several equivalent options. My proposed classes would
keep a (kind of) adjacency list/matrix in the System class that explicitly
define these links. If I understand your proposal, your idea is to keep
an array of Step objects that reference their neighbors internally.
 These two representations are essentially equivalent and shouldn't make any
difference to the end-user, so I don't have a particularly strong opinion
about which is the better.

  Keep the ideas flowing :)


More information about the Biopython-dev mailing list