Hi Vince, You raise an important point that a common use of the chipDb objects will become overly complicated with this change. Especially since chip platforms should really have an implicit genome that they were designed for from the get go. And since annotations packages are being build right now there isn't time to address all of these problems optimally so I am going to put these deprecations on ice till sometime after the release.
Thanks for you feedback, Marc On 09/22/2014 08:03 PM, Vincent Carey wrote: > Thanks for the clarification. Isn't there a way via active bindings > to preserve the > interfaces conferred by e.g., illuminaHumanv1CHRLOC, so that queries > to the > object (no longer a Bimap) succeed with the endorsed metadata? the > chipDb > packages would be revised to use a new protocol for these queries that > go through > TxDb. > > On Mon, Sep 22, 2014 at 8:38 PM, Marc Carlson <mcarl...@fhcrc.org > <mailto:mcarl...@fhcrc.org>> wrote: > > Hi Vince, > > So if you wanted to do this manually, then the thing you would > want to do is to get a gene ID from the probe and to take that to > a TranscriptDb object (again: that is if you wanted to do it > manually). Alternatively, if you had an OrganismDb object then > this association would be handled for you (where it would be > spelled out explicitly). The explicit nature is what we are after > here since where a gene is expected to be (chromosome wise) can > depend on the build of genome you are using. As people move > between standard genomes and eventually to custom ones, we needed > to decouple this kind of data from the organism packages (which > are only ever intended to hold gene-centered data). > > Marc > > > > On 09/21/2014 08:21 AM, Vincent Carey wrote: > > On Sun, Sep 21, 2014 at 11:07 AM, Martin Morgan > <mtmor...@fhcrc.org <mailto:mtmor...@fhcrc.org>> wrote: > > On 09/21/2014 07:44 AM, Vincent Carey wrote: > > this is coming out of the build system for GGtools ... > not easy to find as > the > > problem seems to cause emission of megabytes of warnings > > > illuminaHumanv1CHR is deprecated as the data is better > accessed from > > another location. Please use an appropriate TxDb > object or package for > > this kind of data. > > > i don't see the deprecation in the doc for > illuminaHumanv1.db and i cannot > > get a get() to throw it. i also don't see this on the > devel version > package landing page > > Marc will likely reply on Monday. But the intention is > that the CHR bimaps > in *db packages Marc curates are being deprecated. The > deprecation itself > occurs in AnnotationDbi, I think. The reason is the lack > of provenance for > this information -- what genome build does it refer to? -- > and its > availability from other sources (i.e., the TxDb packages) > with provenance. > > > Nice to hear about the streamlining and improved provenance. > I confess I > don't > see how to get a probe-chr mapping out of TxDb -- is there > something new in > there? > A select operation that can resolve queries about manufacturer > identifiers? > > > illuminaHumanv1CHR > > illuminaHumanv1CHR is deprecated as the data is better > accessed from > another location. Please use an appropriate TxDb object > or package for > this kind of data. > CHR map for chip illuminaHumanv1 (object of class > "ProbeAnnDbBimap") > > I think this is currently a message, but should be a warning. > > AnnotationDbi is not building successfully, so its > biocLite() version and > landing page are not in sync with an svn checkout (used by > the build > system); to replicate on your own system requires an svn > install, at least > until AnnotationDbi builds successfully. > > OK, so I can get the message now. But I think more details > need to be > supplied if > we are to drop references to *CHR. > > > I guess the megabytes of warnings come from code in > GGtools or elsewhere; > maybe there's a > > > Indeed. Perhaps unrelated to this. > > convenient way of aggregating them (hopefully before throwing > the warning, > > since that can be quite expensive). > > Martin > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org > <mailto:Bioc-devel@r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > -- > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M1 B861 > Phone: (206) 667-2793 <tel:%28206%29%20667-2793> > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> > mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
