On Tue, Sep 21, 2010 at 12:43 PM, Vincent Carey
<stvjc@channing.harvard.edu>wrote:

> On Tue, Sep 21, 2010 at 12:16 PM, Steve Lianoglou
> <mailinglist.honeypot@gmail.com> wrote:
> > Hi,
> >
> > On Tue, Sep 21, 2010 at 12:09 PM, Vincent Carey
> > <stvjc@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.
>
>
Just to add here that the org.Hs.eg.db packages are based on NCBI data,
generally speaking.  The GenomicFeatures stuff is generally based on UCSC
data (or some other source chosen by the user).  The annotations from these
various sources will not be equivalent in all cases, particularly when it
comes to chromosome positions.

To make things even more complicated, since there have been numerous refseq
releases from NCBI over the three years from 2006-2009, the org.Hs.eg.db
packages during those years will generally NOT be the same from one release
to the next even though the reference genome was unchanged.


> 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.
>
>
This point cannot be overstated.  While in some cases this might work,
designing workflows with these kinds of hacks in place are bound to lead to
difficulties at some point (always 2 days before a grant deadline or a
national talk).


> >
> > -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
> >
>
> _______________________________________________
> Bioconductor mailing list
> Bioconductor@stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/bioconductor
> Search the archives:
> http://news.gmane.org/gmane.science.biology.informatics.conductor
>

	[[alternative HTML version deleted]]

