[cement_head]

As described, the benefit of using this kit is to permit the researcher a sensitive method to distinguish whether fragments with the same start-end positions arose from distinct cDNAs (the "8 reads, 8 fragments" scenario of Figure 2) or from PCR duplication (the "8 reads, 4 fragments" scenario).

In the paragraph at the bottom of page 4 (below Figure 3) it states (emphasis mine),


The problem of distinguishing "reads originate from the same or different cDNA molecule" IS the issue of PCR duplication. This whole study focuses on a protocol to distinguish fragments arising from PCR duplication from fragments arising from distinct but identical cDNAs prior to amplification. The paper then makes the assertion that reads with identical start-end coordinates are "usually assumed to be clonal (i.e. PCR) duplicates". That is a reasonable assumption to make for genomic DNA sequencing but not for RNA-Seq, and it's an assumption I never make for RNA-Seq; in fact I assume just the opposite. I never perform any duplicate removal if I am doing an RNA-Seq experiment involving counting reads.

Both panels in Figure 5 need a third line added showing the "Total reads" for each of the ERCC controls or mRNA species. If the "Total reads" curve is not significantly different than the "Molecular indexing" then using this protocol for RNA-Seq doesn't add much.

Nope - You've misinterpreted the paper. It doesn't actually say that - it says that using the USS alone is problematic - but the combination of USS and STL is not.

[kmcarr]

Nope - You've misinterpreted the paper. It doesn't actually say that - it says that using the USS alone is problematic - but the combination of USS and STL is not.

I stand by my statements. USS would be problematic if duplicate removal was standard practice for RNA-Seq data. It is not.

Second, they failed to present any data demonstrating significant levels of PCR duplication in the data in the first place. What is needed in Fig. 5 is a curve plotting number of reads mapped for each of the 24 ERCC controls or mRNAs with out first doing any de-duplication by either USS alone or USS+STL. Only if that curve was significantly higher than the USS+STL curve (blue line in Fig. 5) could they make for adding molecular indexes to RNA-Seq libraries.

What the white paper is attempting to do is to sell a solution without first demonstrating a problem which needs solving.

[cement_head]

I stand by my statements. USS would be problematic if duplicate removal was standard practice for RNA-Seq data. It is not.

Second, they failed to present any data demonstrating significant levels of PCR duplication in the data in the first place. What is needed in Fig. 5 is a curve plotting number of reads mapped for each of the 24 ERCC controls or mRNAs with out first doing any de-duplication by either USS alone or USS+STL. Only if that curve was significantly higher than the USS+STL curve (blue line in Fig. 5) could they make for adding molecular indexes to RNA-Seq libraries.

What the white paper is attempting to do is to sell a solution without first demonstrating a problem which needs solving.

I believe you are incorrect. Despite the assumption that any fragment that is identical with respect to USS is likely a PCR duplicate, it turns out that this is not the case. Not removing true duplicates would misrepresent (overestimate) the original (pre-PCR) molecule population in the biological sample. If you are not removing duplicates in an RNA-Seq analysis, then you are relying on statistical tests to de facto do so during the analyses stages - especially in the cases of DGE experiments. The approach of using molecular indices (STLs) in combination with USSs clarifies which of the fragments is PCR artefact based and which fragments were originally present in the biological sample.


Here is a link to example data that demonstrates the difference between USS usage and USS + STLs usage: http://www.biooscientific.com/Portal...lar-Labels.pdf

I hope this clears up your queries.

Regards,
Andor

[cement_head]

For CLC Genomics Workbench:

https://www.qiagenbioinformatics.com/plugins/molecular-indexing