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
qpcr data, and the latter to normalise it using a reference gene, or
calculating a normalisation factor by combining several reference
implements the deltadeltaCt method for normalisation, and Normfinder
geNorm, two popular existant algorithms, are also implemented, which
the user to search for the optimal reference gene(s) in a given
I developed the package along with Matthias Kohl, the author of
which implemented geNorm, but didn't offer any easy way to get the
into the correct structure for the algorithm to work, it seemed
provide something more analagous to e.g. the affy or oligo package, to
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
slot, exprs.well.order, which contains information on the spatial
of the wells on the qPCR plate.
We chose to do this instead of using the qPCRSet in HTqPCR largely for
reasons you point out, i.e. not having to maintain code, and also so
algorithms developed for eSets could be used on the qPCRBatch object
directly, as well as it seeming good practice to reuse the currently
That said, I personally believe that the two objects can co-exist
HTqPCR has far superior functionality to Read/NormqPCR for QC for
and does a number of things that my packages doesn't. Perhaps the
more bespoke qPCRSet of HTqPCR enables this functionality to be
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
of class "qPCRBatch" and vice versa.
On 27 November 2011 16:11, Laurent Gautier <email@example.com> wrote:
> Hi Heidi,
> I am currently looking iwith interest at your package HTqPCR and I
> the following question and suggestion.
> The class "qPCRset" is really looking like a sort of "eSet" (defined
> Biobase), just without "phenoData" or "assayData". Would it make
> get qPCRset to inherit from "eSet" ? This would likely facilitate
> of functionality in "Biobase" (and free you from having to maintain
> Moreover, in the documentation for the examplar datasets "qPCRraw"
> mentioned that the 3 TagMan arrays "are 3 different samples with 2
> replicates each". Unfortunately, the only available information
> the samples are sample names such as "sample1", "sample2",
> "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
> 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
> store sample information in a separate object (which was what the
> 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
> Bioconductor mailing list
<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]]