[Bioperl-l] BPlite as SeqAnalyisParserI

[Jason Stajich]

I'm just going to return the HSPs so that BPlite next_feature will keep
track of the Sbjct and when it exhausts the current Sbjct of all of its
nextHSP calls I'll try and get a new Sbjct, when there are no more Sbjcts
to get then the next_feature will return undef.

This is the simpliest way to do this without major changes to the code,
BPlite::Sbjct objects really don't hold any information other than the
name of the query so it is useless to try and make them a SeqFeatureI.
HSP contains all the relavent information so I'll just return HSPs.  It
will be up to the user to interpret that some HSPs are attributed to
different query seqs (by looking at hsp->query->seqname).

-jason

On Mon, 19 Feb 2001, Ewan Birney wrote:

> On Mon, 19 Feb 2001, Hilmar Lapp wrote:
> 
> > Jason Stajich wrote:
> > > >
> > > > I'm afraid at the same time I'll have to issue an exception permit
> > > > for the SeqFeature::Gene stuff to settle down, and for BPlite
> > > > (Jason, any chances?) to adopt the SeqAnalysisParserI interface.
> > > > I'd still like to expire these permits Monday night.
> > > 
> > > Hmm, in order to do this, either we make Bio::Tools::BPlite::Sbjct a
> > > SeqAnalysisParserI or we need to find a way to make a Sbjct a SeqFeatureI
> > > which doesn't really make sense to me.
> > > 
> 
> 
> I had the smae problem in HMMER, which has a HMMSequence and a (badly
> named) HMMUnit which is a featurepair.
> 
> I flattened the array of HMMSequence (each of which has an array HMMUnits)
> to just an array of HMMUnits. 
> 
> 
> This is what we do in the Ensembl "runnable" system as well, so it is a
> tried and tested route...
> 
> 
> 
> 
> > 
> > The SeqAnalyisParserI is supposed to convert input into a stream
> > of seqFeatures, so Sbjct cannot take that role. It should be
> > possible to make Sbjct a SimilarityPair-derived object, which will
> > make it a SeqFeatureI automatically. Check out
> > Bio::SeqFeature::SimilarityPair::_fromBlastObj(), where I create a
> > SimilarityPair object from a Blast::Sbjct object (or a Blast::HSP
> > alternatively).
> > 
> > So, provided BPlite::Sbjct can be made to inherit off
> > SimilarityPair, next_feature() in BPlite.pm would simply return
> > one subject after another, until there are no more. If changing
> > BPlite::Sbjct to inherit off SimilarityPair is too cumbersome,
> > next_feature() could also grab the next BPlite::Sbjct object and
> > create a SimilarityPair instance from its properties, much like
> > SimilarityPair::_fromBlastObj() does it from a Blast::Sbjct.
> > 
> > Sounds okay? Am I missing something?
> > 
> > 	Hilmar
> > -- 
> > -----------------------------------------------------------------
> > Hilmar Lapp                              email: hlapp@gmx.net
> > GNF, San Diego, Ca. 92122                phone: +1 858 812 1757
> > -----------------------------------------------------------------
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> > 
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>. 
> -----------------------------------------------------------------
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

Jason Stajich
jason@chg.mc.duke.edu
Center for Human Genetics
Duke University Medical Center 
http://www.chg.duke.edu/