[Biojava-l] [newio] Proposed event-notification interfaces
Thomas Down
td2@sanger.ac.uk
Fri, 10 Nov 2000 11:21:12 +0000
On Thu, Nov 09, 2000 at 02:58:39PM -0800, Ann Loraine wrote:
>
> > - Potential to handle `feature-only' formats like GFF and GAME.
>
> You could build a double-parser that extracts coordinates from
> a GFF/GAME file and then grabs the corresponding sequence out of
> a fasta db.
Yes indeed. This idea makes me lean even further towards
the idea that there should be some special mechanism on
the SeqIOListener interface for notifying a database ID
(so that you can easily write a SequenceBuilder which listens
for this, then goes and fetches the sequence data).
Then a structure like this should work nicely:
GFFParser ---> FetchSymbolsSequenceBuilder ---> DefaultSequenceBuilder
^
|
FastaParser <------+
> Please allow in-between residues annotations as well as
> on-top-of residues annotations.
>
> For instance, in-between annotations are useful for mapping splice
> sites onto alignments. On-top-of anotations are useful for flagging
> individual residues.
This isn't really an issue for the I/O framework -- I'd
assumed that the parsers would just generate standard BioJava
Location objects. It's the current Location interface which
forbids `between positions' locations -- in particular, the use
of inclusive coordinates.
I guess it should be possible to change the Location interface,
although doing this without breaking too many of the current
semantics might not be easy.
Up to now, I've always seen the splicing problem in terms of
exon and intron features, which can be modeled fine using our
current interface, but I can see that if you want to deal with
individual splice sites, matters become harder.
> I would focus on designing the event class so that it can adequately
> capture the information being parsed, and then write your listeners
> based on the events.
My current prototype for the SeqIOListener owes more to the
SAX DocumentHandler interface and friends than to AWT event
listeners. I'm not sure we actually need any/many specialized
event objects -- instead, I've been trying to think about each
type of record that a parser might find, and add suitable
notification methods for each. The closest I've got to using
an event object is for the startFeature notify, where the
existing Feature.Template (and subclasses) objects are used
to wrap up the Location and other basic information for the
feature.
As things stand at the moment, the database IO of the
sequence would be passed to listeners using the
addSequenceProperty notification. But probably it's
important enough that we should have either a special
notification method, or pass it as a parameter to the
existing startSequence notification.
Thanks,
Thomas.
--
``If I was going to carry a large axe on my back to a diplomatic
function I think I'd want it glittery too.''
-- Terry Pratchett