New pipeline: nf-core/protaga

[michalxlevin]

Pipeline title/name

proteotranscriptomics assisted gene annotation

Keywords

transcriptome assembly, gene annotation, peptide evidence

What is it about?

The pipeline takes raw sequencing reads (FASTQ), performs quality control, read correction, trimming, alignment, and then uses the cleaned data for either De novo transcriptome assembly (Genome-free, GF) or Genome-guided transcriptome assembly (GG). The outputs from both assemblies then undergo annotation, quantification, and quality assessment, and finally proteomics-based validation, including tools like BUSCO, TransDecoder, MaxQuant, Transrate, and Detonate.

Please provide a schematic diagram of the proposed pipeline

I confirm my proposed pipeline will follow nf-core guidelines. Most importantly, my pipeline will:

• be built with Nextflow.
• pass nf-core lint tests and use standardized parameters.
• be community-owned and developed within the nf-core organization.
• open source under the MIT license with proper credits and acknowledgments.
• have a descriptive, all lowercase, and without punctuation name.
• use the nf-core pipeline template and predominantly use official nf-core modules.
• focus on a specific data/analysis type with appropriate scope.
• have properly maintained documentation.
• be bundled using versioned Docker/Singularity containers.

Why do we need a new pipeline?

We work with this pipeline quite some time and found it useful in a myriad of different research fields especially where genome assemblies and annotations are not of high quality.

Who would be interested?

Any researcher who would like to apply transcriptomics or proteomics in an organism that is not annotated satisfactory will be able to build his own database with protein coding genes with peptide evidence. The data can either be produced from scratch with simple paired end sequencing and mass-spectrometry measurements from the organism and tissue of interest or publicly available data can be used.

What has been done so far

I have a running nextflow pipeline which performs all steps smoothly.

URL to existing work (if applicable)

The pipeline sits on my gitlab account

Are there any similar existing nf-core pipelines?

No response

[nf-core-bot]

Approval status: 🕐 Pending

Required approvals: Either 2 core team members OR 1 core team member + 1 maintainer

Review Status	Team members
🕐 Pending (Core)	@ewels, @maxulysse, @mribeirodantas, @mashehu, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @jfy133, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart, @nvnieuwk
🕐 Pending (Maintainer)	@pontus, @maxulysse, @lpantano, @pinin4fjords, @mashehu, @JoseEspinosa, @mirpedrol, @GallVp, @FloWuenne, @matthdsm, @FriederikeHanssen, @adamrtalbot, @mahesh-panchal, @jfy133, @atrigila, @prototaxites, @ramprasadn, @edmundmiller, @luisas, @SPPearce, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[nf-core-bot]

Approval status: 🕐 Pending

Required approvals: Either 2 core team members OR 1 core team member + 1 maintainer

Review Status	Team members
🕐 Pending (Core)	@ewels, @maxulysse, @mribeirodantas, @mashehu, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @jfy133, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart, @nvnieuwk
🕐 Pending (Maintainer)	@pontus, @maxulysse, @lpantano, @pinin4fjords, @mashehu, @JoseEspinosa, @mirpedrol, @GallVp, @FloWuenne, @matthdsm, @FriederikeHanssen, @adamrtalbot, @mahesh-panchal, @jfy133, @atrigila, @prototaxites, @ramprasadn, @edmundmiller, @luisas, @SPPearce, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[jfy133]

Thanks for the proposal @michalxlevin !|

Without a background in the field, at first glance this proposal looks quite similar to: https://nf-co.re/denovotranscript/1.2.1/

Could you maybe compare and make a summary of how big the difference is, and if there a reason why you would not be able to join forces and collaborate on the existing pipeline?

[michalxlevin]

Thanks for the proposal @michalxlevin !|

Without a background in the field, at first glance this proposal looks quite similar to: https://nf-co.re/denovotranscript/1.2.1/

Could you maybe compare and make a summary of how big the difference is, and if there a reason why you would not be able to join forces and collaborate on the existing pipeline?

The proposed pipeline has an important add-on which is mass-spectrometry evidence for the assembled transcripts. This is the major added value. In addition, the transcriptome assemblies can be done in a genome-free and a genome-guided manner. Technically the Trinity part in our proposed pipeline is a bit more efficient as it separates the assembly process into different substages which intrinsically have very different memory and cpu requirements and thus this process is shortened by more than a third in time depending on the amount of data input (https://dl.acm.org/doi/10.1145/2335755.2335842). Also the main goal of our efforts is to publish the pipeline in a manuscript including a lot of RNASeq but also Mass-Spectrometry data that was collected during many years for this purpose. As far as I now see the denovotranscript pipeline was published last week (https://currentprotocols.onlinelibrary.wiley.com/doi/abs/10.1002/cpz1.70248).

[michalxlevin]

Maybe the above was not clear enough. In the pipeline we use raw Mass-Spectrometry data to validate the predicted open-reading frames. We have shown that this procedure adds another very important layer of confidence to the predicted coding transcripts (https://genome.cshlp.org/content/33/1/112, https://pubmed.ncbi.nlm.nih.gov/33023468/, https://pubmed.ncbi.nlm.nih.gov/35891789/).

[jfy133]

I'm still not entirely following - I think as I'm not familiar with the tools, at least based on the diagram, where does the mass spec data come in? Is this coming in in the Channel.fromPath() just above MAXQUANT/DETONTATE A more schematic/cartoon diagram emphasising the main novelty, would be useful here for non-experts :)

Please note the desire to publish does not prevent you from adding new functionality to a new pipeline and publishing a paper describing this new functionality (and thus is not taken into considerations during proposals), as we value more collaboration, teamwork, and longevity of pipelines.

In the meantime lets get some feedback from developers of existing transcriptomics pipelines for their expert thoughts (even if not a direct overlap in all cases) @avani-bhojwani @timslittle @erikrikarddaniel

[michalxlevin]

Sure, any input is more than welcome. And joining force even more! I also include a more schematic outline of the pipeline for better understanding.

[jfy133]

I've pinged the developers of denovotranscript again on Slack to see if we can get their feedbackl :)

[erikrikarddaniel]

We already have an overlap between #metatdenovo and #denovotranscript. They do many things similarly, I think, but address different audiences. The former is meant for meta-omics (metaT and metaG) while I think the latter is more for single organism transcriptomics. Having access to proteomes is probably much more likely for single organisms, and it hence feels to me that features in this proposal (proteomics + assembler) could/should be added to #denovotranscript.

Another aspect of this is that there's a potential overlap with proteomic pipelines. Perhaps there's a potential for reuse via shared subworkflows there.

[timslittle]

Hi @michalxlevin, sorry for not responding sooner.

I am inclined to agree that the majority of this pipeline is similar to https://nf-co.re/denovotranscript/1.2.1, although your application has additional functionalities and of course the mass spec integration. It is not clear to me whether these are best suited for adding to the existing pipeline or a new pipeline (your proposal). My hunch would be that it would be neater for the possibility of mass spec integration to be a feature added onto denovotranscript, since they are essentially performing the same process up until that point. The example of genome-guided Trinity assembly would be of value in the existing pipeline too and should not be difficult to add as an additional option.

I am interested in why you perform both genome-guided and fully de novo Trinity. What is the rationale for this, and how are they later combined?

I hope that this helps!

Best wishes,
Tim

P.S. Re publication, if it is decided to combine your proposal into denovotranscript, then if your pipeline exists as a fully formed entity you could always publish it yourself, shared from Gitlab but not an official nf-core pipeline, and then add the novel features into denovotranscript as an official nf-core pipeline.

[michalxlevin]

Dear Erik, dear Tim,
Thanks for the input. Indeed in principle the overlap is the biggest with denovotransript.
We usually perform both assemblies (genome-free and genome-guided) and compare the outputs, as for some transcript assemblies the one gives better results than the other. Combined with Mass-Spectrometry peptide evidence this often provides a much more comprehensive picture in specific cases. Overall we did observe that denovo assembly is the better for most transcripts, especially when genome assemblies are problematic. I think Tim's suggestion to first publish the general pipeline as is separately would be a quicker endeavor. As we are tight on time this is probably the most straight forward way. If of interest we can continue discussing integrating the additional features in denovotranscript.

[avani-bhojwani]

I would agree with Tim. I also wanted to add that with there has been a case (nf-core/sarek) where a second publication was produced for a pipeline after it was updated significantly, so that is an option. However, publishing as a general pipeline would be faster. Yes - happy to discuss integrating additional features in denovotranscript in the future. It would be good to check-in with a couple of others in the #denovotranscript channel on Slack about it too, as they were considering adding annotation steps to the pipeline a few months ago.

[jfy133]

OK it seems then we seem(?) to be going in the direction that:

1. The current developed pipeline will be published independently of nf-core due to time constraints
2. Then maybe integrate the latter part of the pipeline into #denovotranscript to help build a larger development team as well as offer more functionality?