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

[Scott Cain]

Mark,

For representing this in GFF3, I would point you to the current version
of the spec at http://song.sourceforge.net/gff3.shtml.  About two thirds
the way down it talks about similarity data.  The important points are
these:

  - be sure to use a SO term for the type (ie, match or one of its
children)

  - escape spaces and other stuff in the ninth column

  - don't bother trying to represent data using the reserved keyword
Gap, as nothing understands how to parse it yet (I think) (unless of
course you are going to add parsing functionallity to BTGFF and BDGFF
:-)  What all this means is you need one gff line for each HSP, even
though technically, you wouldn't need to do that if you could use the
Gap keyword.

Scott

On Fri, 2004-01-09 at 12:01, Mark Wilkinson wrote:
> 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
-- 
------------------------------------------------------------------------
Scott Cain, Ph. D.                                         cain at cshl.org
GMOD Coordinator (http://www.gmod.org/)                     216-392-3087
Cold Spring Harbor Laboratory