[Bioperl-l] v1.0.1 BLAST SearchIO woes

[Jason Stajich]

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 you are more than welcome to make suggestions or
improvements.




-jason


 On Tue, 25 Jun 2002 JDiggans@genelogic.com wrote:

>
> I just upgraded to the 1.0.1 bioperl release while at the same time
> reworking a bunch of BLAST parsers and have found several issues w/ using
> SearchIO. I'm hoping I'm just missing something obvious but it seems like
> Jason and Steve C. are still working towards moving into one unified BLAST
> parser and I'm running into issues caused by this temporary middle-ground.
>
> Specifically, I need strand information from each HSP. Jason's blast.pm
> returns HSPs as GenericHSP objects which, when queried for their strand
> acc. to one of two ways offered by HSPI to ask for stranded-ness, seem to
> return the name of the strand instead of the expected -1/1. i.e.:
>
>         print $currHSP->strand('query')."\n";
>         print $currHSP->strand('sbjct')."\n";
>
> prints out:
>
>       query
>       sbjct
>
> instead of:
>       1
>       1
>
> Checking the SearchIO.t file there are tests for accessing strand
> information through GenericHSP objects via:
>
>       $genericHSP->query->strand();
>       $genericHSP->hit->strand();
>
> which do work, but why call it 'hit' instead of 'sbjct'? Was this for
> backwards compatibility? Get's confusing w/ the Search/Hit family of
> objects, IMHO. Why not offer an hsp->sbjct->strand() accession method and
> alias it to hsp->hit->strand() for backwards compatibility?
>
> Checking GenericHSP and BlastHSP it seems that BlastHSP does indeed return
> -1/1 using the first series of method calls. Steve C's psiblast.pm (which
> seems to be a general-purpose report parser? did this start out just for
> psiblast?) returns BlastHSP objects. This fixes my stranded-ness problem.
> However, BlastHSP doesn't seem to have a score() method to return the bit
> score from the encapsulated HSP, though GenericHSP does (and HSPI does not,
> which is probably why it's not in BlastHSP?).
>
> So ... what's the plan for SearchIO BLAST stuff? I don't mind submitting
> fixes but with all the whirlwind development that's going on I'm not sure
> what's a problem and what's intentional or even who does what when it comes
> to SearchIO and I don't want to step on any toes and I don't see any
> obvious bug reports for this behaviour.
>
> So ... if someone could fill me in ... :)
> -j
>
> -------------------------------------------------
> James Diggans
> Bioinformatics Programmer
> Gene Logic, Inc.
> Phone: 301.987.1756
> FAX: 301.987.1701
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>

-- 
Jason Stajich
Duke University
jason at cgt.mc.duke.edu