[Bioc-devel] FW: GO offspring consistency

Marc Carlson mcarlson at fredhutch.org
Fri Dec 5 19:14:55 CET 2014

Hi Jelle,

Thank you for your patience in waiting for my answer here.  It took me a 
lot longer to properly test and validate this than I initially expected.

So if you look at amigo you can see these graph views that show you what 
the current terms up and downstream of a given GO term should be:


vs  it's offspring term.


And you can see (if you click on the inferred tree view for GO:0006915) 
that GO:0042981 is actually listed there as an offspring term.

Which just that leaves us with the mystery of why:

     all(subsetapt %in% setapt)

Would ever return false?

Now to do some more digging, if we carry your example one step further 
we can do this to extract the specific terms that have this surprising 

subsetapt[!subsetapt %in% setapt]

And lets look closer at the very 1st result (out of 3) that we see: 

So now we would then expect that: GO:0006915 -> GO:0042981 -> GO:0035602

Especially since the very latest amigo diagrams show this set of 
relationships for this term.


But if we look more closely at this term we can notice something unusual 
about it.  Specifically if you look at the Graph views you will see that 
it has a 'part of' rather than an 'is a' relationship to the rest of the 
DAG.  An examination of the other two non-compliant terms indicates that 
they too have this kind of relationship:



Also of interest is the fact that the highest level term you tested  
(GO:0006915), has a broader kind of relationship to the rest of the 
DAG).  Now please hold onto those thoughts while I tell you another 
important fact.


The contents of the GOBPOFFSPRING mapping are ultimately derived from 
the graph_path table that you can find here:


And they are indeed a faithful representation of what is in that table 
(from GO).  That is, the source files both when I made the latest GO.db 
package for the October release and now have the same properties for 
their set of relationships as you pointed out.  So for our 1st example, 
in both places you will find that "GO:0035602" is listed as having an 
implied link when you ask for "GO:0042981" but not when you ask for 

So the very unsatisfying answer to your question is that the terms have 
this relationship because that is what the data at GO say. :P

But the (hopefully) more satisfying answer is that the kind of 
relationships that these terms have to each other creates implications 
for whether or not they can be transitively associated in the GO 
graph_path table.  That is, the child term "GO:0035602" is not able to 
be implicitly linked to "GO:0006915" because that term has a 'regulates' 
relationship to the offspring terms and *also* because "GO:0035602" has 
a 'part of' relationship (instead of an 'is a' relationship) to its 
parent terms.  And those issues don't crop up between the other terms in 
this part of the graph.

I hope this explains things better for you,


On 12/02/2014 04:29 AM, Jelle.Goeman at radboudumc.nl wrote:
>   Hi All,
> When working with the GO.db package we ran into a seeming inconsistency in the GOBPOFFSPRING object. It seems there that a term's offspring may have offspring that is not offspring of the term itself. This seems inconsistent with the DAG structure of gene ontology.
>> library(GO.db)
>> xx <- as.list(GOBPOFFSPRING)
>> setapt <- xx$"GO:0006915" #apoptosis
>> subsetapt <- xx$"GO:0042981" #offspring of apoptosis
>> "GO:0042981"%in%setapt
> [1] TRUE
>> all(subsetapt %in% setapt)
> [1] FALSE
> Is there something wrong or are we misunderstanding the GOBPOFFSPRING object?
> Best wishes,
> Jelle
> Het Radboudumc staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629.
> The Radboud university medical center is listed in the Commercial Register of the Chamber of Commerce under file number 41055629.
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

More information about the Bioc-devel mailing list