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

[Mark Wilkinson]

On Fri, 2004-01-09 at 10:05, Jason Stajich wrote:

> Personally I never really expected to use HSP->gff_string because there is
> 2 separate pieces of information below there and you will want
> each one in different contexts so HSP->gff_string doesn't make a lot of
> sense to me in the first place.

I agree entirely!  This is what I was implying with my
->gff_string('hit') and gff_string('query') suggestion (though that is a
bit infantile, I know, it was just the concept that I was trying to
bring to light).

> My view is that all the Search objects should be data containers and it is
> up to the user to determine how to use them rather than pre-packaging too
> much on the data object level.

I think I understand what you mean.  You've obviously given this more
thought than I have, so if you suggest what the API should look like IYO
then I would try to code it according to that spec.  We could make a
start in moving things that direction!  (or is this going to break
everything if we start it?)

I think the root of the problem is that Gbrowse expects a very peculiar
type of GFF in this circumstance, so we are kind of stuck writing
peculiar code :-)  Nevertheless, since Bio::DB::GFF is part of BioPerl,
I believe we have to be internally consistent and enable the creation of
this GFF format from inside of BP.

Just to bring up the question again - what is the correct way to
represent this in GFF3, since I assume that Gbrowse will support GFF3
"without tweaking" ... or do we look forward to GFF3.5?  ;-)  It might
make more sense for me to code this as a GFF3 feature, rather than spend
the time trying to get the GFF2.5 to look right...

M