Operons in JBrowse2

[sgiorgetti]

Hello guys,

I have a question about operon's representation in JBrowse2.

If I load a track from GFF3 file in which operons are "standalone" features - say something like

contig	C1	operon	6366331	6369596	.	+	.	genes=gene1,gene2;Name=operon1;ID=operon1
contig	C1	operon	6441644	6446465	.	+	.	genes=gene3,gene4;Name=operon2;ID=operon2

All looks good and I can see the features displayed in my (linear) view.

If instead I describe the operon like

contig	C1	operon	6366331	6369596	.	+	.	genes=gene1,gene2;Name=operon1;ID=operon1
contig	C1	gene	6366331	6366431	.	+	.	ID=gene1;Name=mygene1;Parent=operon1
contig	C1	gene	6368096	6369096	.	+	.	ID=gene2;Name=mygene2;Parent=operon1

it does not get rendered ... nor its gene subfeatures.

Am I doing anything wrong? May you kindly advise?

[cmdcolin]

unfortunately I think JBrowse 2 (and JBrowse 1 for that matter) may not handle operons super-well, however, the fact that you are not seeing it render at all is odd.

I tried copying your second example, and I was able to see it render though

i can't really be sure why you aren't seeing anything at all...the most common reason for things not rendering at all is that the 'refnames' don't match (first column of gff with names in fasta file) but not sure that applies in your case

[sgiorgetti]

If confirmed, I suppose this is a bug, which would end the discussion.

[cmdcolin]

what would you think the expected behavior might be for JBrowse to do to handle this properly? JBrowse could potentially 'ignore' the operon level of the feature during rendering maybe, at least as a starting step maybe

[cmdcolin]

it could even be that our data adapter strips the operon level of the feature. as nice as the "generalized" nature of the GFF3 child->parent hierarchy is, there often are assumptions for how those hierarchies need to be rendered by e.g. JBrowse that needs lots of hard coded stuff for e.g. how to draw a transcript, how to draw a exon subfeature of a transcript, etc. (at least how we have it currently! it would be great if the rendering could be more generalized too!)

[sgiorgetti]

Ignore the operon level could be a convenient and temporary solution from system/dev perspective, but researchers would benefit (i.e. need) the operon to be rendered somehow.
From system's point of view, the operon is a group of genes and stays one level up the hierarchy, as you mentioned.

During a workshop for gathering requirements for Apollo3, users fancied genes in an operon could be coloured the same. Not sure if this helps or not (guess not).
Shall have a chat with my JBrowse2/Apollo3 developer - and some users too - to see if we get a "decent" idea to share with you. Happy to help, as sorting this would be great to us too :-)

[sgiorgetti]

@cmdcolin - apologies for my belated follow up.

Had some discussions around, which I can summarise as follows, albeit not bringing brilliant ideas or elements to the discussion:

• An operon is a group of genes, close to each other, as far as the current/official understanding goes.
• These genes should be co-regulated, but this part is not captured by the GFF3 specs, yet - EOY 2023.
• Colour coding is nice from user perspective, but it would probably require some further ad-hoc hardcoding or spurious attributes in the GFF3 9th field. I would therefore suggest to keep the current rendering (rectangle enclosing the genes).
• Could not wrap my head around "rules" for paving the way to a "more generalised rendering of the features".
• This operon thing is something under consideration in the Apollo context. Not sure if there are synergies worth exploring.