[BioC] Hg18 build of org.Hs.eg.db

[Vincent Carey]

On Tue, Sep 21, 2010 at 12:16 PM, Steve Lianoglou
<mailinglist.honeypot at gmail.com> wrote:
> Hi,
>
> On Tue, Sep 21, 2010 at 12:09 PM, Vincent Carey
> <stvjc at channing.harvard.edu> wrote:
>> I believe the best way would be to install the "release" version of R
>> that coincides with the org.Hs.eg.db
>> version that you are interested in, and install it into that version
>> of R with biocLite.  In my lab we have
>> simultaneous availability of R 2.10, 2.11, and 2.12 (and now 2.13) to
>> allow continuity of ongoing analyses.
>> The user must pick the appropriate version.
>
> While this generally works, it's somehow non optimal for this
> particular problem especially because the package in question is an
> annotation package.
>
> Consider the situation where the user wants to use Rsamtools (not
> available in R 2.10) but is performing analyses against hg18.

Fair point.

>
> One could argue that perhaps the GenomicFeatures package would be
> better suited to replace the genome-version-specific info I'm guessing
> the OP wanted from org.Hs.eg.db, but I'm just giving an example.

Perhaps.  The GenomicFeatures approach does allow the user to specify the
build and makes the user responsible for maintaining that image of the
feature metadata -- it is not part of
a distributed package.  And if I am not mistaken, the way one will
most likely get richer metadata from the
makeTranscriptDb... result is by decoding the transcript names or
entrez ids used with an org.Hs*
table.

If one really needs an hg18-based set of org.Hs* mappings, one might
be able to use sqlForge facilities
of annotationDbi package to make it and install it alongside the
distributed org.Hs*, with a distinguishing
package name.  I say "might" here because the reliance of this
facility on possibly genome-build-dependent metadata
is not completely clear to me; Marc Carlson may want to comment.

But I do believe one wants to avoid the temptation of taking an
"older" org.Hs* package and installing it in
a newer, mismatched version of R.  You might get away with it in some
circumstances but it is not a good
idea.  It is possible to create some simple interversion
communications so that answers to queries against an R 2.10-based
resource can be used in R 2.12 for example, and that would be much safer.

>
> -steve
>
> --
> Steve Lianoglou
> Graduate Student: Computational Systems Biology
>  | Memorial Sloan-Kettering Cancer Center
>  | Weill Medical College of Cornell University
> Contact Info: http://cbio.mskcc.org/~lianos/contact
>