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]]
