[Biojava-l] Alignments

[David Waring]

> -----Original Message-----
> From: Matthew Pocock [mailto:matthew_pocock@yahoo.co.uk]
> Sent: Tuesday, May 14, 2002 2:02 PM
> To: David Waring
> Cc: biojava
> Subject: Re: [Biojava-l] Alignments
>
>
> Hi David,
>
> David Waring wrote:
> > I will soon be adding a bunch of classes related to Alignments. I should
> > have these ready today or tomorrow. I hate naming things so if
> anyone can
> > come up with better names especially for ARAlignment I am open to
> > suggestions.
> >
> > Interface UnequalLengthAlignment (allows having sequences of different
> > lengths)
>
> I presume that this is api-short-hand for inserting gaps before or after
> a particular sequence in the alignment? This would be functionally
> equivalent to using a gapped sequence to view the alignment component
> and adding gaps at 0 or at length.

This is not exactly the same as gaps before and after. Take for instance an
alignment of a small clone, and a larger reference sequence. The clone has a
finite length shorter than the chromosome, so at the ends there is not a
gap, it is just null. We could come up with a new Symbol to represent this
but I think null works.


> > Interface ARAlignment (allows adding and removing sequences)
>
> Usefull functionality
>
> > Interface EditableAlignment (allows editing, and shifting bases)
>
> Again, usefull to have.
>
> > Class FlexibleAlignment (implements all 3 of the above)
> > Interface AlignedElement (holds label, SymbolList, location)
> > Class SimpleAlignedElement
> > Abstract Class AbstractULAlignment
> > Class IllegalAlignmentEditException
> > Interface QualitativeAlignment (handles SymbolList that implement
> > Qualitative)
>
> Could you explain what Qualitative means?

Qualitative is defined in biojava.bio.program.phred package. In the case of
PhredSequence it represents the quality score given by Phred or Phrap. there
is just one method qualityAt().

>
> >
> > May I suggest a few other things
> >
> > Interface SequenceAlignment (extends Alignment)
>
> Long overdue. Thomas, how hard would it be to knock up a
> SequenceAlignment class that was composed from an alignment and a
> feature holder?
>
> > I think this could help in the recently discussed issues about
> > SequencePanel. Anyone up for defining this one?
> >
> > In addition I REALLY think that we need an interface for a
> GappedSymbolList.
> > Since this name is already taken I guess we could call it GappedList or
> > something. This way GappedPhredSequence or other classes could implement
> > this interface.
> >
>


> What methods would the gapped interface contain? I would be happy to
> make GappedSymbolList an interface and add a SimpleGappedSymbolList.
> Perhaps that would make people mad. The idea of GappedSymbolList was
> that it wrapped another symbol list, adding the ability to view it with
> gaps. GappedSequence does the same for a Sequence instance, and takes
> care of projecting features from un-gapped to gapped coordinates. Both
> classes have (or should have) methods to fetch the underlying object
> being viewed. Perhaps the need for your gapped interface goes away if we
> have a generic 'View' interface, and code would walk down the decorating
> views untill they hit one that has the funcitonality they want. Grr.
> Sometimes I don't like OOP.

The gapped interface would contain the methods in GappedSymbolList. I see
that we now have GappedSequence which is what I am after. But we also have
GappedPhrepSequence, which with the exception of the capitolization of
method names could implement the gapped interface. I suspect that renaming
GappedSymbolList would cause a bunch of headaches so a different name for
the interface might be in order
>
> How much of your new API do you think should be added to Alignment,
> rather than to derived interfaces? All the funcitonality that you have
> mentioned would seem to me to be sensible to add directly to Alignment
> (pending knowing the exact semantics of the calls you are adding).

I think that ARAlignment,EditableAlignment and UnequalLength alignment could
be all rolled into the Alignment interface, but that would mean potentially
breaking things. Adding them all as separate interfaces seems better, then
anyone can choose to implement the features they want. I actually prefer
this given the experience of SymbolList where most implementation actually
don't implement edit(), so it is kind of a broken API.


> >
> > I have some questions about how to best implement change support for
> > EditableAlignment. Particularly how should changes that cascade
> be handled.
> > Let me first define the function 'shift'. This will move bases in one
> > direction or the other, filling in gaps on one side and adding
> gaps on the
> > other. Of course shifting cannot delete bases only gaps. In the
> case of an
> > UnequalLengthAlignment shifting bases that include the first or
> last base
> > should not add gaps at the ends, rather it changes the location of the
> > sequence withing the alignment. So there are two types of
> changes, adding
> > removing gaps, and changing location. In addition if a sequence
> is shifted
> > such that it extends the overall alignment, it will change the
> size of the
> > alignment. Finally if a sequence at the begining of an
> alignment is sifted
> > to the left, the whole alignment will shift so as to make the
> first base in
> > the alignment = 1 again. In this cases all of the sequences in
> the alignment
> > must be changed. The same is true if an sequence is added to
> the alignment
> > that extends the alignment to the left.
> >
> > Now how should changes be signaled to listeners. Should each
> change be sent
> > with a FirePreChangeEvent/FirePostChangeEvent. Or should I just
> come up with
> > a global ChangeEvent, that holds all the information? If each
> change, gets
> > sent individually, it seems that there is a possiblity
> (although it should
> > not happen) that a one of the events gets vetoed, and I'd have to do a
> > rollback. I know this sort of things has been discussed before
> but I don't
> > know what the conclusion is. I would like to send ChangeEvents
> that will let
> > the listeners know what sequences have been changed, and the
> overall range
> > of the change so that, for instance, some Rendering object
> would know what
> > it had to redraw without having to figure it all out for itself. Any
> > suggestion would be appreciated
>
> This is where the current changeability API is a bit suckey. You can set
> it up so that the alignment listens for changes in the individual
> sequences, and forwards these (wrapping the change event as appropreate)
> to listeners on the alignment. ChangeForwarder is your friend here. So,
> when a request comes in to alter the alignment, if it will directly
> affect a property of the alignment you first fire pre-changes on the
> alignment, then call the method on the symbol lists or alignment that
> will make updates and then fire post-change. If it does not directly
> alter a property of the alignment (but may do indirectly), you call the
> appropreate method directly. When the object the alignment is composed
> from changes, it will fire pre and post change notifications, and the
> change forwarder in the alignment can pass this information on to the
> appropreate listeners.
>
> This mess is made a bit more robust on the BRANCH_CHANGE branch as there
> are seperate interfaces for registering listeners and forwarders, but we
> are getting ahead of ourselves. Does that make things clearer? I'm most
> of the way through a rather good shiraz, so my explanation may not be
> crystal.
>
> Matthew


I understand the forwarder stuff, but my real question is whether a listener
should be given one changeEvent that encompasses all the predicted changes
or let them all come as they will. In the later case, one change to the
alignment could give many changes to the listeners so it could trigger
multiple redraws of a window, instead of a single redraw when all the
changes were finished.

I guess I also have a question about the ChangeEvent itself. Is it supposed
to hold all the information necessary for the listener to replicate the
changes??? In the simplest case the ChangeEvent can describe the changes
that are going to be made, so a Listener could reflect those changes. But in
the case of more complicated changes, it is impractial to try to explain all
the changes to the listener, but rather it seems to me, the listeners should
be alerted that changes are being made, they can Veto them if the wish but,
after they receive the postChange, they should look back at the event source
to see what has happened.

I think sometimes that a bottle of shiraz might help me understand this
better.

David

>
>