[BioPerl] Re: [Bioperl-l] gff_string on an HSPI object is not
markw at illuminae.com
Fri Jan 9 17:42:41 EST 2004
On Fri, 2004-01-09 at 14:59, Jason Stajich wrote:
> Perhaps you want an HSP-2-SO type factory or something (which is basically
> what is in the script...).
that is likely the way to go, yeah.
> As for the .. versus + -
> What does:
> my @values = $feature->get_tag_values('Target');
> print join(",", at values), "\n";
> give you?
ugh! Here is where your complaint about calling ->gff_string on the HSP
object really shows its colours! Of course, calling ->get_tag_values on
the HSP object throws an exception, since it isn't *really* a feature...
and neither of the two Alignment Feature objects has a tag named
"Target", so this information is clearly being tacked onto the output of
I think the default behaviour of $HSP->gff_string is weird, in that it
assumes you want the query sequence to be the reference sequence in the
GFF (i.e. I think that what Gbrowse wants to see is MORE correct). I
could almost tolerate it if it chose the database sequence as the
reference sequence. However I agree with you entirely that $HSP should
probably not have a gff_string method at all. It just leads you into
temptation... and delivers you straight to evil! >-}
I think for the moment I will continue modifying my GFF report writer
so that it functions in a similar way to your utilities script in converting
a ResultI object into GFF(1,2,2.5,or 3) just as a stop-gap measure because
I need it quickly! It will take more time/thought/work to write an HSP_2_SO
What do you see as the future for Bio::Tools::GFF in light of this conversation?
It seems that it would need to become a lot smarter in order to deal with the
more rigourous requirements of GFF3...
More information about the Bioperl-l