[Bioc-devel] lumi annotations

Hi all,

I am developing a package with intention to use data from several
microarray platforms and the related annotations in a portable manner.

Given an ExpressionSet "eset", I have been using constructs like

library(annotate)
m <- getAnnMap('SYMBOL', annotation(eset))
s <- get(featureNames(eset)[1], m)

which seems portable and works fine on Affymetrix data I have used so far.

Turning to Illumina and lumi package the same does not work anymore:
------------------------------------------------------------

library(lumi)
data(example.lumi)
m <- getAnnMap('SYMBOL', annotation(example.lumi))

Error: getAnnMap: package lumiHumanV1 not available

biocLite('lumiHumanV1.db')

Using R version 2.12.0, biocinstall version 2.7.4.
Installing Bioconductor version 2.7 packages:
[1] "lumiHumanV1.db"
Please wait...

Warning message:
In getDependencies(pkgs, dependencies, available, lib) :
  package ?lumiHumanV1.db? is not available
------------------------------------------------------------

Is this just a bug in the example.lumi object, or is it simply wrong to
assume that the same mechanism should work with lumi at all?

Antti

Hi all,

I am developing a package with intention to use data from several
microarray platforms and the related annotations in a portable manner.

Given an ExpressionSet "eset", I have been using constructs like

 > library(annotate)
 > m <- getAnnMap('SYMBOL', annotation(eset))
 > s <- get(featureNames(eset)[1], m)

which seems portable and works fine on Affymetrix data I have used so
far.

Turning to Illumina and lumi package the same does not work anymore:
------------------------------------------------------------

 > library(lumi)
 > data(example.lumi)
 > m <- getAnnMap('SYMBOL', annotation(example.lumi))

Error: getAnnMap: package lumiHumanV1 not available

 > biocLite('lumiHumanV1.db')

Using R version 2.12.0, biocinstall version 2.7.4.
Installing Bioconductor version 2.7 packages:
[1] "lumiHumanV1.db"
Please wait...

Warning message:
In getDependencies(pkgs, dependencies, available, lib) :
   package ?lumiHumanV1.db? is not available
------------------------------------------------------------

Is this just a bug in the example.lumi object, or is it simply wrong
to assume that the same mechanism should work with lumi at all?


Antti

--
Antti Honkela
Antti.Honkela at tkk.fi   -   http://users.ics.tkk.fi/ahonkela/

Speaking of annotations...

The 450k methylation chips have arrived and many of the probes map to
multiple accessions.  I have modified the 27k annotations from Sean to
handle bead mapping IDs (thanks Sean!) and started building probe sequence
packages in the style of matchprobes/beadarray, but I was wondering how
people would like to handle multiple-accession mappings and/or NuID encoding
of the 450k probes.  As I'm sure many of you are aware, the denser platform
contains many more probes with multiple CpG sites, which affects both
preprocessing and the manner in which it makes sense to apply NuID
translations. There are other 'interesting' aspects of the 450k arrays,
along with consequences arising from the design of the platform, but a good
first step would be to get the data playing nicely with methylumi and lumi,
hence some agreement upon the annotations.

Also, given the large number of controls on the platform, a means of keeping
track of (e.g.) bisulfite conversion controls and non-polymorphic probes, as
well as the 600 or so negative controls, belongs in MethyLumiM.  How this
should best be accomplished is less clear to me -- it's trivial to pull the
control probe intensities from the .IDAT files that are always emitted from
every scan of a 27k or 450k chip, but the representation within the object
is more troublesome.  One of the things that made combining and subsetting
MethyLumiSet objects quirky on occasion was the eSet-within-an-eSet
representation for control probes, so I understand your (plural) reluctance
to continue that model.  However, the only other thing I can come up with is
to use an additional couple of data.frame() objects to hold the Cy5 and Cy3
control intensities.  That would be fine too.

This raises the question of how to store information about the control (and
analytic!) probes.

Two package types make sense:

1) IlluminaHumanMethylationXXk.db -- probe annotations like Sean has built
for the 27k and GG arrays (small and compact)
2) illuminaHumanMethylationXXkProbe.db -- addresses and probe sequences for
the analytic and control probes (larger .db)

Thoughts?  I mostly work from .IDAT files these days, and the Cambridge guys
have expressed interest in making bead-level tools play nicely with
methylumi/lumi.  Regardless of where the data comes from, it would be nice
to standardize on representations, and leave room for using low-level data
as appropriate.  (I've seen referees ask paper authors whether they looked
at bisulfite control probes, for example -- not an unreasonable question,
but the current MethyLumiM can't answer it.)

I've been impressed with the cleanliness of the Lumi methylation codebase,
and it would be great if a consensus arose about data representations and
annotation, so that this cleanliness is not disrupted.  For example, I have
built 27k and 450k probe packages, and the 450k annotation package can be
built without much trouble if a consensus can be reached as far as mapping
multiple accessions to probes (or perhaps using a GRanges object or
GenomicFeatures?!?).

Patching the current  MethyLumiM object to handle
subsetting of a couple additional data.frames is no problem either.  But I'd
like to get your thoughts on the matter before I go off and hack up your
code.  :-)

Thank *you* for your thoughtful replies.  I'd forgotten how control probe
data is stored in LumiBatch objects.  That seems like the most consistent
way to handle it for MethyLumiM objects, now that you mention it; using
addControlData2lumi(), but with both channels represented, such as in a list
with $Red and $Grn data.frames.  Using getControlData with a "MethyLumiSet"
type would do the trick; I can easily write this, in fact.  I'll send a
patch.

As for multiple mappings, I am not sure how Illumina 450k reports them. For
easier maintenance in the long run, we can just keep the same way as
Illumina do. Illumina has improved their annotation maintenance. They make
regular updates of their annotations now.

The most recent manifest is available via iCom, but partly because Sean had
to do all the heavy lifting last time around, I'm planning to push out at
least a SQLite package of probe NuID/channel/chemistry annotations as
illuminaHumanMethylation450kProbes.db.  In the Illumina annotations, the
accession numbers are concatenated with semicolons, with as many as 6
separate accession numbers provided per probe.  I don't think anyone had
this scenario in mind when the AnnotationDbi package and its mappings were
designed :-)

Will do.  I've been working on a package so that Infinium methylation chips
can be handled the way expression or SNP chips are (in 'beadarray'/'lumi' or
in 'crlmm').   I plan to put up a vignette showing a mixture experiment on
the 450k arrays and the 27k arrays, comparing the various preprocessing
options and their effects on each platform, but if there are no objections
from the investigators, I'll see if I can't just post the control probe data
this week.

If you can send me some example control data, I can play with it and update
the MethyLumiM class at the end of this year. If possible, please also send
me one or two samples of 450K data with annotation information.

I'll see if I can't get it turned around this week.  A typical 450k array is
(as you might imagine) rather larger than the corresponding 27k array (~15MB
vs ~1.5MB of IDAT files) but the controls are just a few K (and no mapping
or normalization is required for them).  So I don't imagine it would be much
trouble to post some examples on GitHub.