Another question Re: [BioC] question on hgu95 metadata and ontoTools

Elisabetta Manduchi manduchi at pcbi.upenn.edu
Tue Jan 13 16:43:18 MET 2004


I think I found an easy solution to the question I had posed below.
Namely I was setting 

obs<-ls(env=hgu95GO)

which limited my observations to the 12625 probe sets on av2.
By resetting

obs<-hgu95.probeset

where the latter is the union of the probesets for all 5 chips and then 
proceeding as before:

> ooMapHgu952GOBP<-otkvEnv2namedSparse(obs, tms, hgu95GO)

things seem to work as desired.
Sorry if I wasted anybody's time on this question.
Elisabetta


On Mon, 12 Jan 2004, Elisabetta Manduchi wrote:

> 
> Hi,
> I'm writing with a questions that follows up on a previous correspondence 
> I had within this mailing list (copied below).
> Essentially I'm trying to use ontoTools to ge a mapping between the union 
> of the probe sets on the HGU95 av2, b, c, d, e and GO biological process 
> terms.
> To this end, I've first created an environment, named hgu95GO, which was 
> defined as described below, using parent.env, following a suggestion by R. 
> Gentleman: 
> 
> > hgu95GO<-hgu95av2GO
> > parent.env(hgu95GO)<-hgu95bGO
> > parent.env(hgu95bGO)<-hgu95cGO
> > parent.env(hgu95cGO)<-hgu95dGO)
> > parent.env(hgu95dGO)<-hgu95eGO
> 
> For this we have
> 
> > length(ls(env=hgu95GO))
> [1] 12625
> 
> which is the same as the length for hgu95av2GO, rather then the length of 
> the union of the 5 probe set collections from av2 to e (which is 62906). 
> However if I look for a value of a key corresponding to a probe set from 
> b, c,... indeed it gives me something by looking at the parent. I'm not 
> too familiar with environments in R, but I guess this is the expected 
> behavior. Now, I've built a mapping:
> 
> ooMapHgu952GOBP<-otkvEnv2namedSparse(obs, tms, hgu95GO)
> 
> where tms are the nodes of a go biological process graph that I've built 
> and obs is ls(env=hgu95GO).
> I'm concerned though that since the latter seems to be equal to 
> ls(env=hgu95av2) only, I'm not getting the mapping that I desired from 
> the union of all *5* collections of probe sets on the 5 Affy chips to my 
> GO BP terms and indeed if I run:
> 
> > ooc.Hgu95.GOBP<-makeOOC(goBPonto, ooMapHgu952GOBP)
> > print(OOmap(ooc.Hgu95.GOBP))
> named sparse matrix of dim[1] 12625  7807
> 
> the first dimension is 12625, not 62906. Am I correct in my 
> interpretation that I'm not getting what I was seeking? If so, how can I 
> get around it? I.e. what would be the quickest way to build a mapping from 
> the union of the probe sets on the 5 Affy Chips to my Go BP ontology?
> Thanks for any help you might give me,
> Elisabetta
> 
> On Wed, 17 Dec 2003, Elisabetta Manduchi wrote:
> 
> > 
> > Robert,
> > thank you very much for such a prompt reply.
> > A question, with your notation below, shouldn't I do my gets on E5 rather 
> > than on E1, if E1 is the ancestor? Was that a just typo or am I 
> > misunderstanding?
> > In other words to deal with my case, I guess I could do the following 
> > (calling hgu95GO my new combined environment):
> > 
> > hgu95GO<-hgu95av2GO
> > parent.env(hgu95GO)<-hgu95bGO
> > parent.env(hgu95bGO)<-hgu95cGO
> > parent.env(hgu95cGO)<-hgu95dGO)
> > parent.env(hgu95dGO)<-hgu95eGO
> > 
> > and then do my gets on hgu95GO, right?
> > Elisabetta
> > 
> > On Wed, 17 Dec 2003, Robert Gentleman wrote:
> > 
> > > On Wed, Dec 17, 2003 at 03:47:54PM -0500, Elisabetta Manduchi wrote:
> > > > 
> > > > Hi,
> > > > I would like to create an environment that combines the hgu95av2GO, 
> > > > hgu95bGO, ...hgu95eGO into just one environment, that I can subsequently 
> > > > use as the otkvEnv argument in the ontoTools function otkvEnv2namedSparse.
> > > > Is there a quick and simple way to do this in R, without having to define 
> > > > a new hash and the key-value mapping block by block (according to which 
> > > > environment the key belongs to)? In other words, I'm asking if there is a 
> > > > one-stop way in R to "union" the above 5 environments.
> > > 
> > >  Sort of, in R there are no hash tables but environments are close so
> > >  we used them. They have a rather unique aspect which is the parent
> > >  environment. So that if a value is not found in the first environment
> > >  the parent is searched. So to solve your problem you could do some
> > >  thing like
> > > 
> > >    parent.env(E2) <- E1
> > >    parent.env(E3) <- E2
> > >  ...
> > > 
> > >   then do your get's on E1 (with inherits=TRUE, which is the default
> > >   in get) and you should be almost set. The one issue that is not
> > >   easily solved is the if inherits is TRUE then you search up beyond
> > >   the last of your environments (your work space and then the search
> > >   list). But that should not be a problem in your case....
> > > 
> > >    Robert
> > > 
> > > > Thanks,
> > > > Elisabetta
> > > > 
> > > > _______________________________________________
> > > > Bioconductor mailing list
> > > > Bioconductor at stat.math.ethz.ch
> > > > https://www.stat.math.ethz.ch/mailman/listinfo/bioconductor
> > > 
> > > 
> > 
> > 
> 
> 

-- 
Elisabetta Manduchi

Computational Biology and Informatics Laboratory
Center for Bioinformatics
University of Pennsylvania
1428 Blockley Hall
423 Guardian Drive
Philadelphia, PA 19104-6021

phone: 215-573-4408
fax: 215 573-3111
email: manduchi at pcbi.upenn.edu
web: http://www.cbil.upenn.edu/~manduchi

---



More information about the Bioconductor mailing list