[Biojava-dev] Biojava Interface to BLAST web/remote services

[Scooter Willis]

Sylvain

I think the way you submit the query/paramaters of the seearch or parse
a BLAST file would be different and we would not worry about the SAX
API/File dependency of parsing a file. We do need a Class that would
contain the search parameters and this should as an object follow the
same inputs available via the union of HTML interfaces for the supported
BLAST engines. Some search engines will have more inputs or specificity
over others so that will require some analysis. This search parameter
class should be independent of a particular BLAST web service engine
allowing a user to submit the same search to multiple services with
minimum overhead. 

But once you get the results then having the ability to use the same
general iteration of results/hits will allow those who have invested in
the BLAST file parsing API to easily insert the new web services
approach.

>From the biojava cookbook SeqSimilaritySearchHit is the class that
contains the results and should be the class used to contain the results
from the web service query. In the web service approach you should be
able to get the collection of SeqSimilaritySearchResult and
SeqSimilaritySearchHit from each of the supported BLAST web services.
The assumption is that SeqSimilaritySearchResult and
SeqSimilaritySearchHit have been properly designed to represent BLAST
data. 

Scooter

      //output some blast details
      for (Iterator i = results.iterator(); i.hasNext(); ) {
        SeqSimilaritySearchResult result =
            (SeqSimilaritySearchResult)i.next();
 
        Annotation anno = result.getAnnotation();
 
        for (Iterator j = anno.keys().iterator(); j.hasNext(); ) {
          Object key = j.next();
          Object property = anno.getProperty(key);
          System.out.println(key+" : "+property);
        }
        System.out.println("Hits: ");
 
        //list the hits
        for (Iterator k = result.getHits().iterator(); k.hasNext(); ) {
          SeqSimilaritySearchHit hit =
              (SeqSimilaritySearchHit)k.next();
          System.out.print("\tmatch: "+hit.getSubjectID());
          System.out.println("\te score: "+hit.getEValue());
        }
 
        System.out.println("\n");
      }
 
    }

-----Original Message-----
From: Sylvain Foisy [mailto:sylvain.foisy at diploide.net] 
Sent: Thursday, June 04, 2009 9:57 AM
To: Scooter Willis; Andreas Prlic
Cc: biojava-dev at lists.open-bio.org
Subject: Re: [Biojava-dev] Biojava Interface to BLAST web/remote
services

Hi Scooter,

That is one way of doing it ;-) I was thinking of creating an object
that
the user would either:

- Feed into the BJ Blast parser
- Do something else entirely.

Best regards

Sylvain

On 04/06/09 09:28, "[NAME]" <[ADDRESS]> wrote:

> Sylvain
> 
> Given that BioJava already has a BLAST file parser that returns
results
> the goal should be to have a remote/web call return the same set of
> classes as if you had parsed the file locally. That is going to be my
> approach. Once we get a couple services working we can integrate into
a
> common factory/interface approach.
> 
> Thanks
> 
> Scooter
> 
> 
> -----Original Message-----
> From: biojava-dev-bounces at lists.open-bio.org
> [mailto:biojava-dev-bounces at lists.open-bio.org] On Behalf Of Sylvain
> Foisy
> Sent: Thursday, June 04, 2009 9:07 AM
> To: Scooter Willis; Andreas Prlic
> Cc: biojava-dev at lists.open-bio.org
> Subject: Re: [Biojava-dev] Biojava Interface to BLAST web/remote
> services
> 
> Hi Scooter,
> 
> On 04/06/09 07:38, "[NAME]" <[ADDRESS]> wrote:
> 
>> Looks like the rolled their own URL interface and did not do a WSDL.
> Not a big
>> deal but does appear they have some sort of submit get a "ticket" and
> then
>> check back with the "ticket" identifier for the results. The BioJava
> API would
>> hide the transport layer so you could use a custom URL approach or
web
>> services. 
> 
> That is basically the way it works. I am working on a
RemoteBlastWrapper
> class that would do exactly what you are writing.
> 
>   
>> Not sure how the other WSDL interfaces handle long running tasks but
I
> assume
>> the Web Services can handle a call that takes say 5 minutes to
respond
> without
>> timing out. Some process would need to distinguish between a long
> running
>> server task and a server that is no longer responding.
> 
> We'll have to try ;-)
> 
> Best regards
> 
> Sylvain
> 
> 
> ===================================================================
> 
>  Sylvain Foisy, Ph. D.
>  Consultant Bio-informatique / Bioinformatics
>  Diploide.net - TI pour la vie / IT for Life
> 
>  Courriel: sylvain.foisy at diploide.net
>  Web: http://www.diploide.net
>  Tel: (514) 893-4363
> ===================================================================
> 
> 
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev