[Bioperl-l] remote blast update

[Chervitz, Steve]

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.

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.

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