Hi all! I'm new to RiboSeq, hoping to quickly figu...
# riboseq
i
Hi all! I'm new to RiboSeq, hoping to quickly figure out a workflow for analysing our soon-to-arrive data - where better to look than nf-core? 😄 We're a non-canonical antigen discovery lab and we want to discover and validate novel/non-canonical ORFs using our riboseq data, with the end goal of assembling a protein fasta file comprising these ncORFs to support mass-spec based immunopeptidomics data analysis. Our samples will be Cycloheximide-treated. From my research so far, it sounds like we're mostly interested in "ORF discovery" more so than other features such as translation efficiency or differential translation analysis. I've been looking at RiboTricer (and other tools) and notice requirements for an input GTF file - does this indicate that it's not design for ORF discovery? Or just that we should use a program to define all possible ORFs within our defined parameters first and then use that gigantic putative ORF list GTF file as input? Appreciate any feedback or suggestions 😄 🙏 thanks!
j
I think this pipeline will do a sensible job at the processing but I dont think we necessarily do the best job on the characterisation of what exactly is translated. The tools that have been added here were just packaged properly to enable their inclusion. In reality you need to be cautious using any of the published tools as you will notice in the literature, few of them agree on what would be 'validated'.
✅ 1
Without looking into it, I assume the gtf is for transcript structure to limit the search space. The search space if you take a whole human genome is massive. Another thing to note is the limitations of having low coverage. The more established annotation efforts (like what we have begun at Ensembl) rely on data aggregation and see that even with millions of reads you fail to pick up many things that really are translated
i
Those are great, helpful notes thank you. We're being promised high coverage but, if that doesn't pan out, we're OK with being able to set filters/thresholds and only take any confident ncORFs identifications with sufficient coverage. As for your caution - I absolutely agree and intend to take a consensus approach where appropriate (similar conclusion reached here: https://academic.oup.com/bib/article/25/4/bbae268/7688817). Please let me know if you do hear of any suggested/recommended tools for de novo ORF discovery from RiboSeq, but otherwise thanks for your help 🙂
j
That is probably the best bet at this current point in time but hopefully in the near future we can do better as a field
s
I second all of Jack's point regarding: rely on annotated gtf first to limit search space; high dependence on coverage for ORF calling (because the 3-nt periodicity on which some ORF calling tools rely is especially hard to detect on low translated / short ORFs). Combining replicates helps to call ORFs with a bit higher coverage, this is why I think the nf-core pipeline includes riboTISH predictions on all bam files combined, alongside predictions on individual bams. If I were you, I would probably start with comparing the novel ORFs called in the standard nf-core pipeline between ribotish and ribotricer - and see if you have any overlap at all 😉 Filtering is essential since raw ribotricer, for example, calls ~ 3x novel ORFs compared to the annotated ones present in Ensembl gtf, and I guess you might want not to break your mass-spec search by including all of them. Beyond nf-core, there are also newer tools such as transformer-based RiboTIE - benchmarking this is on my todo list so would be curious on any comment on its performance if you try it out!