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

