[BioPerl] Re: [Bioperl-l] gff_string on an HSPI object is not Bio::DB::GFF friendly

[Mark Wilkinson]

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
->gff_string post-facto.

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 
factory...

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...

M