HTqPCR and Biobase's eSet
1
0
Entering edit mode
Laurent Gautier ★ 2.3k
@laurent-gautier-29
Last seen 9.6 years ago
Hi Heidi, I am currently looking iwith interest at your package HTqPCR and I have the following question and suggestion. The class "qPCRset" is really looking like a sort of "eSet" (defined in Biobase), just without "phenoData" or "assayData". Would it make sense to get qPCRset to inherit from "eSet" ? This would likely facilitate the use of functionality in "Biobase" (and free you from having to maintain with it). Moreover, in the documentation for the examplar datasets "qPCRraw" it is mentioned that the 3 TagMan arrays "are 3 different samples with 2 replicates each". Unfortunately, the only available information regarding the samples are sample names such as "sample1", "sample2", "sample3", "sample4", "sample5", and "sample6", making it difficult to identify unequivocally which ones are replicates of the same sample. Having "phenoData" information would have made a convenient place for storing such information. There is indeed a supplementary file (mentioned in the vignette but not in the help page for the datasets "qPCRraw" or "qPCRpros"), where sample information are detailed but this is requiring to store sample information in a separate object (which was what the classes in Biobase were trying to help with). What do you think ? I am CC'ing the list in case someone else's would agree, or disagree. Best, Laurent
Biobase HTqPCR Biobase HTqPCR • 970 views
ADD COMMENT
0
Entering edit mode
james perkins ▴ 300
@james-perkins-2675
Last seen 9.6 years ago
Hi Laurent and Heidi, I am a final year PhD student at University College London, and I have created a couple of packages, ReadqPCR and NormqPCR, the former to read in qpcr data, and the latter to normalise it using a reference gene, or by calculating a normalisation factor by combining several reference genes. It implements the deltadeltaCt method for normalisation, and Normfinder and geNorm, two popular existant algorithms, are also implemented, which enable the user to search for the optimal reference gene(s) in a given experiment. I developed the package along with Matthias Kohl, the author of SLqPCR, which implemented geNorm, but didn't offer any easy way to get the data into the correct structure for the algorithm to work, it seemed natural to provide something more analagous to e.g. the affy or oligo package, to read in the data and have it in a biobase/eSet extending object. We decided to create a qPCRBatch class, which extends eset, and adds a new slot, exprs.well.order, which contains information on the spatial position of the wells on the qPCR plate. We chose to do this instead of using the qPCRSet in HTqPCR largely for the reasons you point out, i.e. not having to maintain code, and also so other algorithms developed for eSets could be used on the qPCRBatch object directly, as well as it seeming good practice to reuse the currently available methods. That said, I personally believe that the two objects can co-exist happily, HTqPCR has far superior functionality to Read/NormqPCR for QC for example, and does a number of things that my packages doesn't. Perhaps the slightly more bespoke qPCRSet of HTqPCR enables this functionality to be implemented in a smarter way; qPCRBatch is intentionally pretty simple, as I said before, in part so that users that write algorithms for qPCR can write something that would generalise to any other eSet extending object. I would also like to add that we are thinking of implementing a coerce method (i.e. as()) which converts an object of class "qPCRSet" to an object of class "qPCRBatch" and vice versa. Thanks, Jim On 27 November 2011 16:11, Laurent Gautier <laurent@cbs.dtu.dk> wrote: > Hi Heidi, > > I am currently looking iwith interest at your package HTqPCR and I have > the following question and suggestion. > > The class "qPCRset" is really looking like a sort of "eSet" (defined in > Biobase), just without "phenoData" or "assayData". Would it make sense to > get qPCRset to inherit from "eSet" ? This would likely facilitate the use > of functionality in "Biobase" (and free you from having to maintain with > it). > > Moreover, in the documentation for the examplar datasets "qPCRraw" it is > mentioned that the 3 TagMan arrays "are 3 different samples with 2 > replicates each". Unfortunately, the only available information regarding > the samples are sample names such as "sample1", "sample2", "sample3", > "sample4", "sample5", and "sample6", making it difficult to identify > unequivocally which ones are replicates of the same sample. Having > "phenoData" information would have made a convenient place for storing such > information. There is indeed a supplementary file (mentioned in the > vignette but not in the help page for the datasets "qPCRraw" or > "qPCRpros"), where sample information are detailed but this is requiring to > store sample information in a separate object (which was what the classes > in Biobase were trying to help with). > > What do you think ? > > I am CC'ing the list in case someone else's would agree, or disagree. > > > Best, > > > Laurent > > ______________________________**_________________ > Bioconductor mailing list > Bioconductor@r-project.org > https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.et="" hz.ch="" mailman="" listinfo="" bioconductor=""> > Search the archives: http://news.gmane.org/gmane.** > science.biology.informatics.**conductor<http: news.gmane.org="" gmane.="" science.biology.informatics.conductor=""> > [[alternative HTML version deleted]]
ADD COMMENT

Login before adding your answer.

Traffic: 838 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6