Quantifying novel ORFs I would like to start a discussion about another potential feature for the pipeline. I have started working on this, but figured it probably makes sense to get feedback from the community/main developers of the pipeline, before storming off into the wrong direction. Currently, the pipeline only quantifies ORFs annotated in the GTF file. At the same time, it includes several tools to detect novel ORFs (Ribotish, Ribotricer, RiboCode). Those novel ORFs are not usedin downstream analysis, though (notably, in differential translation and DTE analyses). Is there a particular reason for this other than "we didn't have the capacity to implement this yet"? My current plan is the following: 1. Use consensus ORFs from Ribotish/Ribotricer/RiboCode (ideally user-configurable) 2. Expand the canonical GTF by the novel ORFs 3. Requantify ORF translation from Ribo-seq data using the modified GTF. There are two ways (both of which could be incorporated into the pipeline and offered as a choice to the user): a. Rerun Salmon => complicated, because (1) it will require running the entire quantification workflow - including index generation - nested within the main workflow and (2) Salmon was not really made for the case where there are multiple ORFs for the same transcript. It gives strange results in situations where transcript coordinates are 100% identical: assigning 0 counts to one and the rest of the counts to the other. We would thus need to merge and un-merge transcripts/ORFs before passing them to Salmon and somehow split the counts among the ORFs after unmerging. b. Pass the modified GTF to the in-frame P-site counting => straight forward to implement, but the in-frame P-site counting is under debate 4. Run DTE on the new counts The situation is a bit tricky for ORFs which originate from one and the same transcript. DTE always needs RNA expression for normalization, but you cannot have the same reference transcript for two (or more) ORFs. We would need to synthetically create new transcripts as copies of existing ones and then normalize the novel ORFs to those synthetic transcripts. For example: Let's say a transcript

ENST123

has two ORFs, a canonical one

cORF

, and a non-canonical one

ncORF

. We could use

ENST123

as the matched RNA expression for

cORF

, and a synthetic transcript

ENST123-copy

as a match for

ncORF

. But how to define the counts of the synthetic transcript? Should they be split equally between the

ENST123

and

ENST123-copy

? Or would it be better to duplicate them? In my tests, duplicating the counts seemed better. For example, if

ENST123

had a count of 50, and I made a copy

ENST123-copy

with the same count (50), the DTE results of

cORF

vs.

ENST123

were more stable than when I split the reads among

ENST123

and

ENST123-copy

(25 each). Of course, I did not test this with a single transcript; I ran my tests on 10% of the transcripts.

Hi Sebastian, Regarding the novel ORFs, I don’t have a strong preference. In general, I prefer predicting ORFs in regions with confirmed RNA expression (either already annotated in the GTF or supported by assembled transcripts). In any case, assigning these ORFs the biotype “novel” sounds reasonable to me. But, without overlapping annotated/assembled transcripts, to which transcript would you assign the ORF for downstream analysis? Concerning the DTE analysis, I would agree with duplicating the counts equally. I have used a similar approach before, and it seems to work well.

Thank you for the feedback!

to which transcript would you assign the ORF for downstream analysis?

The ORF callers usually associate the ORF with existing transcripts. I would use whatever they suggest.

Ah great, I thought they only reported them as novel without any associated transcript id

I am a bit concerned about the idea of modifying the GTF and pretending they are different isoforms. If DeltaTE does not support multiple translons per isoform then we shouldnt hack things together to get it to behave. DeltaTE wraps DESeq2 and inflating the counts would surely mess with the size factor estimation. I think this is a problem in translatomics that is entirely underserved by the available software. I think the right approach here is a proper multi-translon DTE model rather than reshaping inputs to fit single-CDS tools. I think building/designing a GLMM for this wouldnt be too hard but validating it would be a headache. Does anyone have experience with anything like this It is great to have you on here @Jorge Ruiz-Orera.

I found DOTSeq, which uses a GLMM to model expression at the ORF level. Does anyone have an opinion on this tool?

I wasn't aware of it! Thank you for sharing. Seems like theyre still working on it? At least at surface level it sounds like they had the same idea I had. What do you think?

It is a fairly new development. Given that the code is available, there is a vignette and a preprint, it may be just about usable. Still, I am a bit worried about stability in a production pipeline. But it is the only tool which models multiple ORFs per transcript that I could find. Would you say that it's development stage is too early to be included into the riboseq pipeline?

Yeah maybe too early but a great one to watch. Thanks again for sharing it. Until then, perhaps we look into your solution and just caveat it