[Bioperl-l] v1.0.1 BLAST SearchIO woes

[JDiggans@genelogic.com]

> you are more than welcome to make suggestions or improvements.

w00t. :)

I'm interested in where the core sees the dual blast.pm/psiblast.pm moving
going forward. Seems like there's quite a bit of redundancy and that both
have certain advantages. Is there a plan w/i bioperl to merge the two,
functionally (though this would be tough since internally they're so
different), or will they remain distinct? Seems like this will get
confusing to newbies, especially given psiblast's somewhat-misleading name.
At the very least they should offer similar functionality ... at the moment
I'd propose doing the following (and yes, I'm willing to work on it):

      - Add a score() method to HSPI ... unless someone can fill me in if
it was
        left out intentionally

      - Add an implementing method to BlastHSP to return scores from HSPs
        pulled from reports
                  (this way it won't matter if a newbie uses blast.pm or
psiblast.pm)

      - Fix the strand('query') access method in GenericHSP which currently
                   returns the word  'query' or 'sbjct' instead of a strand
ID.

Do these make sense? Also, I know there's talk of moving to a more
RecDescent-ish scheme ... how soon is that planned?
-j




                                                                                                                     
                      Jason Stajich                                                                                  
                      <jason@cgt.mc.duk        To:       <JDiggans@genelogic.com>                                    
                      e.edu>                   cc:       Bioperl <bioperl-l@bioperl.org>                             
                                               Subject:  Re: [Bioperl-l] v1.0.1 BLAST SearchIO woes                  
                      06/25/2002 02:28                                                                               
                      PM                                                                                             
                                                                                                                     
                                                                                                                     




HSPs are Bio::SeqFeature::SimilarityPair objects which have the methods
query and 'hit' (and 'subject' which is aliased to 'hit' but deprected),

Now I should note that I may have used bad judgement when I migrated the
SimilarityPair objects from subject -> hit() as this is confusing. In
hindsight, really Hit is a fine object name but $hsp->subject/query is a
more proper pairing that $hsp->hit/query.  I did this was in conjunction
of migrating BPlite from $report->next_Sbjct to $report->next_Hit to me
more explicit about what you were getting.


The following do work:
$hsp->query->strand
$hsp->hit->strand (same as ) $hsp->subject->strand()
using the Bio::Search::HSP::GenericHSP objects.


I personally only use $hsp->query->strand and $hsp->hit->strand and that
is what I test/use so I can't speak to the strand('query|hit') etc.  It
should work but in fact there may be 2 separate storage slots (Data::Dump
out the HSP object and see if you get this, I think this is still the
case) for this information which is really a bad idea.  Grr.  Steve C
likes $hsp->strand('query'), $hsp->length('query') etc style so the clash
of preferences has caused the confusion.  If someone else wants to help on
this project




-jason