Bioperl-guts: bioPerl (fwd)

Ewan Birney
Fri, 16 Apr 1999 17:57:51 +0100 (BST)

On Fri, 16 Apr 1999, Aaron J Mackey wrote:

> > It should use Steve's yet-to-be-written sequence similarity search
> > interface. Steve - for me this is an important thing to write and commit,
> > because there are a number of us who need to use it (Aaron for his fasta
> > results stuff and myself for HMMER2 stuff).
> We should talk about this stuff a bit.  I can't speak for blast or hmmer2
> (well I could try, but I won't), but I can speak for how a fasta
> implementation might work.  The way I see it is you have local
> installations and you have web-accessible servers (ditto for blast and
> hmmer2).  A difference I suspect is that fasta functionality is broken up
> into multiple different flavors, each with overlapping and unique
> parameter sets, and each providing different output formats (again, highly
> dependent on provided parameters).  Again, I suspect this to be true for
> blast and hmmer2.

I agree we should work on make some sort of commonanlity. 

My thought is to make results objects which inheriet from common abstract
interfaces (like GenBank inheriets from DB/Abstract). For me the abstract
interface would look something like:

  Bio::SimilaritySearch::ResultI # I means interface
      o has a hash called parameters?
      o contains a listof
              o name-of-hit method
              o description-of-hit method
              o ?start/end of hit method
              o Has a hash of <name-of-statsitic><value>
              o contains a list of
                Bio::AlignI  # generic Alignment interface. Might be
                             # Simple or Univalign


  Bio::SimilaritySearch::Fasta (for example) would inheriet from 
Bio::SimilaritySearch::ResultsI, and you would have

  Bio::SimilaritySearch::FastaHit etc.

People could then write functions which take a
Bio::SimilaritySearch::ResultI and make html etc, without worrying about
the actual search that was used for this.

Aaron - I don't really understand your LWP analogy (I don't use LWP 
much) but it looks as if you are talking about something which is more
about how the results object is actually made (which I am less worried 
about) and perhaps suggesting that the results object factory could be
generic which I am not sure about.

Lets keep talking - does this message make any sense?

(PS - steve - are we any closer to seeing a real, live 0.05?).

> So far I have written some FASTA parsing scripts which return "Results"
> objects.  Currently these results objects describe parameters of the
> search, statistics of the search, etc.  Eventually I plan on the result
> object itself being able to produce individual "Hit" or "Alignment"
> objects, replete with individual score, expectation value, alignment
> characteristics, yadda yadda yadda (having an Alignment object would be a
> good thing ...)
> I envision this all working much like the LWP modules: a user agent that
> processes a request object (either locally or via the web) and returns a
> result object (which may itself generate a normal file output, or render
> it in HTML for web viewing). The result object may then further generate
> individual "hit" objects as well as aggregate data.  However, the great
> disparity between the three methods (as opposed to LWP::UserAgent only
> having to deal with GET and POST) makes me a little sceptical that such a
> beast could be made to deal with all three algorithms and their myriad of
> options.  Rather, it seems that three separate UserAgents would be
> necessary, with one base class to tie them all together (the base class in
> itself providing little to no functionality besides specifying which user
> agent to use).
> Maybe you've worked out some grander scheme to alleviate my concerns.  I'd
> love to hear about it.
> -Aaron

Ewan Birney

=========== Bioperl Project Mailing List Message Footer =======
Project URL:
For info about how to (un)subscribe, where messages are archived, etc: