SEQanswers

Go Back   SEQanswers > Applications Forums > RNA Sequencing



Similar Threads
Thread Thread Starter Forum Replies Last Post
Create new Reference by merging SNV list with reference genome rdoan Bioinformatics 0 10-12-2012 08:17 AM
running cufflinks with a genome annotation as a strict reference or as a guide. maryb Bioinformatics 2 07-19-2012 06:59 AM
Targeted Genome Assembly for region poorly represented in reference genome? gumbos Bioinformatics 1 01-09-2012 05:01 PM
Modification of reference genome annotation by cufflinks/cuffdiff? markr Bioinformatics 3 07-20-2011 02:20 AM
Reference genome for MAQ - split reference genome by chromosome or not? inesdesantiago Bioinformatics 4 02-18-2009 09:44 AM

Reply
 
Thread Tools
Old 04-17-2013, 04:54 AM   #1
KAP
Member
 
Location: Adelaide, Australia

Join Date: Mar 2010
Posts: 12
Default Is cufflinks still useful if you have a reference genome?

Sorry, the actual heading for my post should be:

If you have a high quality genome annotation, should you always still use cufflinks.

Disclaimer: I suspect I'm missing something so this may be a silly question but I've been thinking about this for years and am still puzzled so here goes.

I don't think I should use cufflinks for my expt because:

a) I am working on species with high quality annotation (human).

b) Since I'm working with short read fragments (few hundred bp), it is likely that using cufflinks to redefine transcripts would introduce as many/more errors in transcript assembly than it would true novel transcripts, simply because transcripts are best described by long (sanger) sequences and only so much information can be inferred about the which transcript a short read originated from. Sometimes it is impossible to determine which differentially exons at the 5' end are connected to others at the 3' end. This is no fault of the algorithm.

c) Because cuffdiff calculates gene-level expression by summing isoform-level expression, any false/artifactual isoforms may reduce the certainty with which a read can be associated with any individual isoform. This comes down to the principle that the more isoforms there are, the more difficult it is for cuffdiff to accurately deconvolute which isoform the read originated from (as per cuffdiff manual?).

d) aside, I'm inclined to think that if I don't intend to validate novel genes/isoforms then I should stick with published ones - global-level RNA-seq of known genes should be just that.

So, in a nutshell this leads me to thinking the following:

If you're not specifically interested in novel gene/isoform discovery and suspect that you would do more harm than good to your genome annotation by including transcripts which were not supported by Sanger-length sequencing, then this should be your pipeline:

tophat -> bam -> + reference.gtf -> cuffdiff

i.e. no cufflinks step.

Yet every protocol seems to have a cufflinks step, and the -G parameter seems to be the used a lot in this kind of situation (despite the potential issues I mentioned above).

Can anyone comment whether I have missed something/made a fundamental mistake or does my reasoning seem sound? Should I be running cufflinks for general-purpose human genome RNA-seq?

P.S. This is assuming you wan't differential expression, of course. If you only have 1 sample, of course you run cufflinks.

Last edited by KAP; 04-17-2013 at 05:03 AM. Reason: typo
KAP is offline   Reply With Quote
Old 04-18-2013, 01:10 AM   #2
DonDolowy
Member
 
Location: Freiburg

Join Date: Oct 2012
Posts: 56
Default

If I only want a list of DEG I go straight from Tophat to Cuffdiff (skipping de novo steps using Cufflinks and cuffmerge). This is what is written in the cuffdiff manual, so I assume it must be valid!
DonDolowy is offline   Reply With Quote
Reply

Tags
cufflinks cuffdiff, human genome, pipeline, rna-seq

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 10:26 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO