[Bioc-devel] BioC 2.5: Added scanDates slot to Biobase's eSet class - Bioc-devel

Thu, Jun 18, 2009 8:44 AM #

Laurent,
As you mentioned the existing phenoData infrastructure could be used  
to house information like scan dates, scanner model, and scanning  
software version, but this information is not conceptually phenotype  
data and, and adding it to an AnnotatedDataFrame comes with the  
limitation of using reserved words (maybe name mangled like  
.__ScanDates__?) for column names in the AnnotatedDataFrame.

The internal discussion we have been having to making this more  
general is to add a different slot (candidate name arrayData) to eSet  
(and removing the scanDates slot) that would house the type of  
information we have been discussing in a combination of dedicated  
slots like scanDates and a catch all AnnotatedDataFrame slot for less  
universal data. This design would separate the array data from the  
phenotype data and having dedicating slots for important information  
like scan dates would avoid having to manage special columns in an  
AnnotatedDataFrame.

As you rightly point out we need to ensure we support a rich suite of  
functionality like "[", subset, etc., but this can all be handled  
through methods for the eSet class.

Keep in mind that this recent change is just a first step, not a final  
design, and with your help and input from the rest of the BioC  
developer community, we can ensure we end up with a sufficiently  
useful microarray data infrastructure.

Cheers,
Patrick


Quoting Laurent Gautier <laurent at cbs.dtu.dk>:

Patrick,

There are indeed always several ways to address needs, and my comment
is mostly pointing at the fact that creating yet-an-other slot is not
necessary since one can currently store such data into phenoData (into
a column named... say "scan_date").

I would in fact qualify of overbuilding the approach that adds a new
(and exclusive) slot while improving the exiting infrastructure could
perfectly answer the needs. So today it's "scanDates", and next could
be "scannerModel", or "scanningSoftwareVersion".

I have been a little unclear (even to myself) in my comment about using
"[", so here are more details. *If* the extract operator was made to
evaluate expressions such as the function subset() does, or in fact if
a method subset was implemented for eSet objects, storing all
information into phenoData makes such things nice:

# silly example: only get the control data scanned in the future:
eset[, scan_date > date() & treatment == "control"]
# same with subset:
subset(eset, , scan_date > date() & treatment == "control")

# a little longer to write
eset[, scanDates(eset) > date() & pData(eset) == "control"]


If for some reasons a distinction between phenoData and
like-phenoData-but-can't-be-the-same is needed, please do consider the
creation of an AnnotatedDataFrame that contains all of them.



L.





Patrick Aboyoun wrote:

Laurent,
We had some immediate need for scan date information and rather   
than overbuild a system for managing metadata that we may or may   
not need, we opted to start simply and then build up as   
appropriate. There has been some internal discussions about   
managing other metadata along with scan dates, but nothing else has  
 bubbled to the top yet. Your thoughts and design can help speed up  
 this process. The class versioning system in Biobase supports   
iterative development and we can make further changes once we lock   
a design in place. One editorial comment I have is that lots of   
designs are possible for a given need and, for example, the current  
 class properly subsets the scanDates information using "[" despite  
 not being stored in the phenoData (AnnotatedDataFrame) slot.


Cheers,
Patrick


Quoting Laurent Gautier <laurent at cbs.dtu.dk>:

Hi Patrick,

Storing the scan dates is indeed useful information, and is it nice to
have it offered at the parsing stage.
However, first comment would be "does it justify a new slot" to eSet ?

I have been storing scan dates for quite some time now, but opted for
having them in the phenoData as it made more sense to me, both on an
implementation standpoint and on practical standpoint (as standard
extraction of an eset-subset on columns with the "[" operator works).

If having something specific for scan dates is really really wished,
would it make make sense to have that by extending AnnotatedDataFrame ?

In my opinion, the stage at which the the data are extracted (in that
case when parsing the files coming out of the image analysis) should
not dictate where the data are stored.
In fact, it might make it for a nice(r) workflow if the function
reading raw array data could return an eSet-inheriting instance and a
phenoData with information such as dates and file names. I am working
on a workflow that is in fact getting much more data from the header (I
suppose that I'd contribute it when enough time to wrap it up).


Just few thoughts,



L.





Patrick Aboyoun wrote:

Dear Bioconductor developers,
The Biocore group has just committed a change to the BioC 2.5   
code  line (Biobase version 2.5.3) to support the use of   
microarray scan  date in statistical analyses by adding a   
scanDates slot to  Biobase's eSet class. This information can be   
retrieved and set  using the new scanDates and scanDates<-   
function respectively. The  scanDates slot is designed to hold a   
character vector of length = #  of samples, with one character   
element for each sample. (See  help(scanDates) for more   
information.)

In this first round of check-ins we have added affy support of   
this  new slot to functions like ReadAffy and we will be working   
towards  adding this information to other microarray platforms as  
 well.

This change involved bumping the eSet version number from 1.1.0   
to  1.2.0 in the Biobase class definition. In order to minimize   
the  impact of this change, the Biobase methods support both the   
current  eSet version 1.2.0 as well as old 1.1.0 serialized   
objects so  updateObject will not be required to be performed on   
eSet-derived  objects prior to use in other functions. We have   
also tested and  versioned bumped (and patched where needed) the   
following packages  that create eSet-derived classes to minimize   
any package build  issues: ACME, beadarray, beadarraySNP,   
cellHTS2, CGHbase, codelink,  crlmm, GeneRegionScan, GGBase,   
maDB, oligoClasses, ontoTools, puma,  rMAT, SNPchip, and spkTools.

Below is a demonstration of the new functionality. If you   
encounter  any issues related to this change, please e-mail this   
list so the  community can monitor the change.

- The Biocore Team

suppressMessages(library(affy))
example(ReadAffy)

RdAffy> if(require(affydata)){
RdAffy+      celpath <- system.file("celfiles", package="affydata")
RdAffy+      fns <- list.celfiles(path=celpath,full.names=TRUE)
RdAffy+  RdAffy+      cat("Reading   
files:\n",paste(fns,collapse="\n"),"\n")
RdAffy+      ##read a binary celfile
RdAffy+      abatch <- ReadAffy(filenames=fns[1])
RdAffy+      ##read a text celfile
RdAffy+      abatch <- ReadAffy(filenames=fns[2])
RdAffy+      ##read all files in that dir
RdAffy+      abatch <- ReadAffy(celfile.path=celpath)
RdAffy+ }
Loading required package: affydata
Reading files:
/Library/Frameworks/R.framework/Versions/2.10/Resources/library/affydata/celfiles/binary.cel    
/Library/Frameworks/R.framework/Versions/2.10/Resources/library/affydata/celfiles/text.cel

scanDates(abatch)

      binary.cel            text.cel
"01/23/04 14:30:57" "08/29/03 15:12:30"

sessionInfo()

R version 2.10.0 Under development (unstable) (2009-06-12 r48755)
i386-apple-darwin9.6.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
other attached packages:
[1] affydata_1.11.6 affy_1.23.2     Biobase_2.5.3
loaded via a namespace (and not attached):
[1] affyio_1.13.3        preprocessCore_1.7.4 tools_2.10.0

_______________________________________________
Bioc-devel at stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel