gmod-ajax

[Gmod-ajax] jbrowse and the canonical gene

[James C. <ca...@gm...>]

Hi everyone,

Just before I get to my point, I want to say congratulations on
JBrowse.  I think it is the best genome browser I have seen by a long
way.

So I thought I would try out jbrowse with some GFF3 and to warm me up
I went straight to 'the canonical gene' from here:
http://www.sequenceontology.org/gff3.shtml

Now unfortunately, jbrowse doesn't render the CDSs correctly.  This is
because there are multiple lines with the same ID which correspond to
a spliced product that are shown as one giant CDS in jbrowse.
Changing the IDs to be different allows jbrowse to render it
correctly.

So looking further up the GFF3 definition:
"ID Indicates the name of the feature. IDs must be unique within the
scope of the GFF file."

Hmmm... so the canonical gene is wrong!  I suppose this should really
get flagged as a warning when the GFF is parsed rather than silently
merging features.

James

Re: [Gmod-ajax] jbrowse and the canonical gene

[James C. <ca...@gm...>]

2009/11/15 James Casbon <ca...@gm...>:
> Now unfortunately, jbrowse doesn't render the CDSs correctly.  This is
> because there are multiple lines with the same ID which correspond to
> a spliced product that are shown as one giant CDS in jbrowse.
> Changing the IDs to be different allows jbrowse to render it
> correctly.

No, I just queried the GFF3 spec and apparently the canonical gene is correct.

jbrowse's rendering could be considered correct as the glyph does span
the entire feature.  I'm not sure it couldn't be improved though by
actually showing the component blocks in the same way as subfeatures.

James

Re: [Gmod-ajax] jbrowse and the canonical gene

[Mitch S. <mit...@be...>]

James Casbon wrote:
> No, I just queried the GFF3 spec and apparently the canonical gene is correct.
>
> jbrowse's rendering could be considered correct as the glyph does span
> the entire feature.  I'm not sure it couldn't be improved though by
> actually showing the component blocks in the same way as subfeatures.
>   

I talked about this on the GMOD teleconference on Monday, and learned 
about BioPerl's SeqFeatureI::location mechanism that allows a single 
feature to have a location with multiple discontinuous spans.  JBrowse 
should probably support this, but unfortunately it currently doesn't.

The work-around at the moment would be to model your CDS segments as 
individual subfeatures, with different (or no) IDs and a Parent 
attribute pointing to the transcript.

So far in my testing, I've mainly encountered situations where people 
were doing that (modeling CDS segments as multiple subfeatures rather 
than a single feature with multiple locations).  I'd be interested to 
know if people reading this typically encounter one approach or the 
other, and whether y'all have strong opinions about this one way or the 
other.

Sorry about that,
Mitch