[Bioc-devel] eSet questions

[Seth Falcon]

On 20 Aug 2005, khansen at stat.berkeley.edu wrote:
> I do have some hesitations regarding using the eSet class as I do
> not see a lot of validity checking going on:

More validity checking is needed for both exprSet and eset.  Recently,
we've added a common base class for both exprSet and eset called
annotatedDataset.  This gave us a place to put common methods for
accessing phenoData.

We have a feature branch of Biobase that contains some new validity
checking: the new code verifies that the covariates in phenoData line
up with the samples in the expression matrix (matrices in eset).  Here
is the doc for the validation:

  For exprSets, Validate checks to make sure that the columns of exprs
  match the rows of the phenoData.  It is an error if the number of
  exprs columns do not match the number of phenoData rows or if they
  do not have the same names (if names are given).

  It is a warning (no error) if:

  phenoData is missing

  there are no exprs column names or phenoData row names provided
  
  the exprs column names are not in the same order as the phenoData
  row names

  For eSets, the same checks are made and in addition the columns for
  each element of the exprList of the eSet must match (i.e., same
  number of them, same names if provided, and in the same order).

I hope we will merge these changes in soon.  Comments welcome, of
course.

> eq. nothing ensures that the construction has an exprs slot (ok, not
> slot but member of the exprsListNM slot of the eList slot of the
> eSet object). In fact, even thought he comments indicate that the
> members of the exprListNM slot have the same dimension, nothing
> ensures this. Of course this could be solved by me using an
> appropriate validity function, but that seems a bit backwards to me
> (but that may be the intentions?)

Vince said "patches welcome" wrt to additional validity checking.
I'll relax that just a bit and solicit descriptions of validation that
should happen.

> In fact I would be tempted to use a new class like the exprSet  
> without the se.exprs slot... (although I will probably opt for the  
> exprSet class just for consistency).

Creating a new class just to get rid of the se.exprs slot seems like
adding work/confusion to me.  

I'd be curious what other folks think as far as using eset over
exprSet even if you envision only having a single expression matrix.


Best,

+ seth