[BioC] Problem with invalid GO term in HyperGResult object - NOT solved

Herve Pages hpages at fhcrc.org
Wed Sep 26 23:31:48 CEST 2007


Hi Jenny,

We've fixed the problem you reported earlier with the ACCNUM map for arabidopsis.
The new ag and ath1121501 packages will be online soon (we will post again when
they are).

Sorry that my temporary workaround was producing a list instead of an environment
and thanks to Jim and Martin for providing a quick solution to the problem.

Let me add a couple of comments related to this issue:

 - If you use the ath1121501.db package (the SQLite-based versions of ath1121501),
   then you'll be able to use the fixed ACCNUM map right now (don't forget to use
   the latest version of AnnotationDbi though). The most visible difference between
   our new SQLite-based metadata packages and our classic environment-based metadata
   packages is that the maps in the formers are S4 objects (AnnDbBimap objects to
   be precise) instead of environments.
   Don't be afraid by this: we've put a lot of effort to make those objects look
   and feel like environments i.e. you can still use length, ls, mget, eapply, get,
   [[, etc... on them.
   hyperGTest() should work as expected with ath1121501.db. Please let us know if
   this is not the case.

 - In the ath1121501.db package (and soon in the fixed version of the ath1121501
   package), the ACCNUM and MULTIHIT maps are complementary: when a probe id is
   mapped to a single AGI locus ID, then ath1121501MULTIHIT is set to NA:

     > library(ath1121501.db)
     > ath1121501ACCNUM[["246779_at"]]
     [1] "AT5G27520"
     > ath1121501MULTIHIT[["246779_at"]]
     [1] NA

   and when it's mapped to multiple AGI locus IDs, then ath1121501ACCNUM is set
   to "multiple":

     > ath1121501ACCNUM[["264451_s_at"]]
     [1] "multiple"
     > ath1121501MULTIHIT[["264451_s_at"]]
     [1] "AT1G10260" "AT1G11265" "AT1G21945" "AT1G48710" "AT1G58140" "AT3G32415"
     [7] "AT3G59720" "AT3G61330" "AT5G13205"

   You can easily create a new map that contains the "merged" data from the
   2 maps with:

     > ath1121501ALLACCNUMS <- as(ath1121501ACCNUM, "AnnDbBimap")
     > ath1121501ALLACCNUMS[["246779_at"]]
     [1] "AT5G27520"
     > ath1121501ALLACCNUMS[["264451_s_at"]]
     [1] "AT1G10260" "AT1G11265" "AT1G21945" "AT1G48710" "AT1G58140" "AT3G32415"
     [7] "AT3G59720" "AT3G61330" "AT5G13205"

   This works with the SQLite-based annotations only (and it is very fast).
   We will add some examples in the man page for those 2 maps to illustrate
   this "merging" operation.

Cheers,
H.


Jenny Drnevich wrote:
> Thanks Herve, Jim & Martin!
> 
> I've got it working now...
> 
> Cheers,
> Jenny
> 
> At 11:43 AM 9/24/2007, James MacDonald wrote:
>> Martin Morgan wrote:
>>> Probably in Jim's use it makes sense to have parent=emptyenv(),
>>> otherwise you can 'get' symbols that are defined in the global
>>> environment rather than the environment you're looking in.
>> Yup. My bad. I was thinking .GlobalEnv wasn't right, but I couldn't
>> remember what parent=NULL used to do. Thanks for the heads-up.
>>
>> Best,
>>
>> Jim
>>
>>
>>
>> --
>> James W. MacDonald, MS
>> Biostatistician
>> UMCCC cDNA and Affymetrix Core
>> University of Michigan
>> 1500 E Medical Center Drive
>> 7410 CCGC
>> Ann Arbor MI 48109
>> 734-647-5623
>>
>> _______________________________________________
>> Bioconductor mailing list
>> Bioconductor at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/bioconductor
>> Search the archives: 
>> http://news.gmane.org/gmane.science.biology.informatics.conductor
> 
> Jenny Drnevich, Ph.D.
> 
> Functional Genomics Bioinformatics Specialist
> W.M. Keck Center for Comparative and Functional Genomics
> Roy J. Carver Biotechnology Center
> University of Illinois, Urbana-Champaign
> 
> 330 ERML
> 1201 W. Gregory Dr.
> Urbana, IL 61801
> USA
> 
> ph: 217-244-7355
> fax: 217-265-5066
> e-mail: drnevich at uiuc.edu
> 
> _______________________________________________
> Bioconductor mailing list
> Bioconductor at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/bioconductor
> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor
>



More information about the Bioconductor mailing list