[Bioperl-l] remote blast update

Jason Stajich jason@chg.mc.duke.edu
Mon, 9 Apr 2001 18:24:07 -0400 (EDT)

On Mon, 9 Apr 2001, Chervitz, Steve wrote:

> Regarding Bio::Tools::Blast, I've recently re-taken up the task of
> simplifying the parsing code and addressing some long-standing issues. I've
> also thought about having a BlastIO system. It would allow us to isolate the
> code for parsing NCBI and WU-BLAST, which would make for better
> maintainability. (This  would also mean that you couldn't mix different
> flavors of Blast output into the same stream, which Bio::Tools::Blast can do
> now, but I doubt anyone really needs to do).
> The BlastIO stream system would also have to differentiate on the type of
> Blast object you want to build (lite or heavy or whatever). So perhaps you'd
> have BlastIO/ncbi and BlastIO/ncbi_lite.
ok. could do that - will have to see how it plays out.  Is there any other
model we should look to in designing this?

> Having a set of standard interfaces such as BlastReportI, BlastHitI,
> BlastHSPI that define core functionalities for these objects is also a great
> goal. It would permit more code-reuse, allow users to easily play with
> different implementations, and make life easier in the CORBA world.

Would be nice to factor out things that can be used by FASTA so we can
simplify access even more.  AnalysisReportI, HspI (or HSPI), HitI or
something along these lines would be nice if we can do it.  These should
probably be in Bio/ since Bio/Tools really ought to just be code for
handling output from specific programs or for doing specific tasks.

Hilmar will probably have some good ideas here too.


> Steve
> Steve_Chervitz@affymetrix.com
> -----Original Message-----
> From: Jason Stajich [mailto:jason@chg.mc.duke.edu]
> Sent: Monday, April 09, 2001 8:29 AM
> To: Wiepert, Mathieu
> Cc: Bioperl
> Subject: RE: [Bioperl-l] remote blast update
> fine by me, whoever codes it first wins.  I'm looking forward to
> reviewing Harold's stuff.
> In the big picture we have to make a distinction between the
> number of packages required to run something in bioperl.  Pure perl
> solutions are always the best because it puts the least burden on users to
> install a lot of extra packages - on top of that CPAN modules are an easy
> add on - going to CORBA or required Web services makes it even more work
> for a user to get it working on their box.  So we have to consider where
> we want to draw those lines.  I still think using the biojava code is a
> great way to go with this, but if it is too difficult for people to
> install then we have to consider the alternatives.  A native perl XML
> parser should be relatively easy with the XML:: modules.
> More importantly what should be the interface to Blast modules - we have
> quite a few methods if you look at the union of methods of
> Bio::Tools::Blast and Bio::Tools::BPlite.  What functionality do people
> really need?  I'm happy to keep Tools::Blast around if we move it up to
> Bio::Root::RootI spec and simplify some parts of the code (don't think we
> are trying to kill it SteveC, we just seem to have a hard time maintaining
> it).
> -jason
> On Mon, 9 Apr 2001, Wiepert, Mathieu wrote:
> > The Biojava Sax package parses quite a few blast outputs, that would be a
> > good template to start with if there is a need to port that code.  The
> > parser plugs nicely into XSLT processors now as well.  I know that Harold
> is
> > close to having some CORBA work done, so we might just want use the java
> > stuff, rather than port it all?
> >
> >
> > Also XML output is an easy hop here so we are definitely looking for
> > someone to consider writing an XML blast parser - as a BPlite plugin or
> > coder's choice.  Maybe we even go to BlastIO/text, BlastIO/xml,
> > BlastIO/asn.1 structure?  Blast is pretty much the staple of
> > bioinformatics right now so anything we can do to make handling
> > reports easier in bioperl is a big plus.
> >
> >  - Mat
> >
> Jason Stajich
> jason@chg.mc.duke.edu
> Center for Human Genetics
> Duke University Medical Center
> http://www.chg.duke.edu/
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l

Jason Stajich
Center for Human Genetics
Duke University Medical Center