[Biojava-dev] Fwd: [blast-announce] New Version of BLAST XML output

Tue May 12 23:21:06 UTC 2015

Hi Paolo,

I definitely don't want to curb your enthusiasm. What about packaging this
up as a new module in your fork? Then we can review the code base and take
it from there. Some criteria to review this on are A) Ease of maintenance
B) extensibility for BLAST variants C) general applicability for any
database searches (potential to hook up BLAST alternatives)

Andreas

On Sun, May 10, 2015 at 5:04 AM, Paolo Pavan <paolo.pavan at gmail.com> wrote:

> Hello!
> I obviously share the opinion of Peter and Jose. Moreover, as already
> written, I have used this new feature in a second work that I could also
> describe and submit to biojava, if of any interest.
>
> About Andreas' questions:
> " Does your module support psiblast, rpsblast, tblastx and blast+ and what
> versions?": At now, it supports the blastn, blastp, blastx, tblastn and
> tblastx version 2.2.29. I'm not very sure about psiblast and rpsblast, I
> should test it.
> But it has been designed so that to update a single parser (as well to add
> a new search program and still remaining in the designed framework) there
> will be the need to write just a single class. This will keep the code
> simple and neat, very important in my opinion for future developers.
>
> "the disadvantage is that you constantly need to update them to the
> variant of blast plus version of the output file format": this
> unfortunately is a problem that everyone of us have to face if wants to use
> new ncbi programs. It happened for legacy-blast, it happened a lot of time
> for genbank format, it is happening for blast+. Just hoping that they would
> have the kindness explicit the format version inside the xml if not to name
> the program itself in different way, such for example blast3 or blast++, to
> avoid confusion. We can't do anything about that, we can just try to make
> the things simple and easy to reuse.
>
> Just to express my opinion, I think that every bio project should first of
> all address theese "base level" problem more than others to allow the
> developer to focus on higher abstraction details. I'm sure that this will
> be appreciated by the community, increasing the base of users of biojava.
>
> Paolo
>
>
> 2015-05-06 12:15 GMT+02:00 Jose Manuel Duarte <jose.duarte at psi.ch>:
>
>> I'd say that having some common data structure to model the output of a
>> sequence homology search should be benefitial. For instance a blast
>> alternative might appear one day (I'm eagerly awaiting for it!). The common
>> data structure should be able to model the outputs of any of the different
>> softwares.
>>
>> There are already some alternatives to blast:
>>
>> SANS and SANSparallel by Liisa Holm (
>> http://www.ncbi.nlm.nih.gov/pubmed/22962464,
>> http://nar.oxfordjournals.org/content/early/2015/04/08/nar.gkv317.full)
>> USEARCH (commercial) (http://drive5.com/usearch/)
>> BLAT (https://genome.ucsc.edu/FAQ/FAQblat.html#blat3)
>>
>> In fact SANSparallel looks very promising, it's incredibly fast though
>> less sensitive than blast.
>>
>> Cheers
>>
>> Jose
>>
>>
>>
>>
>> On 06.05.2015 10:47, Peter Cock wrote:
>>
>>> On Wed, May 6, 2015 at 6:02 AM, Andreas Prlic <andreas at sdsc.edu> wrote:
>>>
>>>> On Tue, May 5, 2015 at 1:18 PM, Paolo Pavan <paolo.pavan at gmail.com>
>>>> wrote:
>>>>
>>>>> As seen in other Bio projects, aside with Sequence IO and Alignment IO
>>>>> procedures it could have a Search result IO also.
>>>>>
>>>> I never understood why other Bio* projects have special Blast modules.
>>>> Perhaps XML parsing is not as easy as it is in Java? Please see the
>>>> code at
>>>> the bottom of this message.
>>>>
>>> Python at least has a range of XML parsing libraries which are up to the
>>> task. However, as Paolo wrote:
>>>
>>>  The advantage is to define common data structures that models Hsp, Hits,
>>>>> Results without taking care (ie. making abstraction) of the underlying
>>>>> search program.
>>>>>
>>>> This is the big advantage of BioPerl and Biopython's SearchIO module.
>>> You can at least in theory switch between parsing BLAST XML, BLAST
>>> tabular, BLAST plain text (shudder), or another related format without
>>> major changes to your code.
>>>
>>>  and the disadvantage is that you constantly need to update them to the
>>>> variant of blast plus version of the output file format.
>>>>
>>> I think it is much better to have this housekeeping done once centrally
>>> in
>>> a Bio* library that re-invented by anyone parsing the BLAST output.
>>> However, the NCBI BLAST XML output has been fairly stable, and the
>>> new output has a formal schema so should be even more dependable.
>>>
>>> Peter
>>> _______________________________________________
>>> biojava-dev mailing list
>>> biojava-dev at mailman.open-bio.org
>>> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>>>
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at mailman.open-bio.org
>> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>>
>
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at mailman.open-bio.org
> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>

-- 
-----------------------------------------------------------------------
Dr. Andreas Prlic
RCSB PDB Protein Data Bank
Technical & Scientific Team Lead
University of California, San Diego

Editor Software Section
PLOS Computational Biology

BioJava Project Lead
-----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biojava-dev/attachments/20150512/d2827c5a/attachment.html>