[BioPerl] Re: [Bioperl-l] gff_string on an HSPI object is not
markw at illuminae.com
Fri Jan 9 12:01:50 EST 2004
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...
More information about the Bioperl-l