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" #element 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

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:

http://amigo.geneontology.org/amigo/term/GO:0006915

vs  it's offspring term.

http://amigo.geneontology.org/amigo/term/GO:0042981

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 result:

subsetapt[!subsetapt %in% setapt]


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

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.

http://amigo.geneontology.org/amigo/term/GO:0035602

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:

http://amigo.geneontology.org/amigo/term/GO:0044336

http://amigo.geneontology.org/amigo/term/GO:0044337


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.

http://amigo.geneontology.org/amigo/term/GO:0006915


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

http://geneontology.org/page/lead-database-schema#go-optimisations.table.graph-path

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 "GO:0006915".

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,


 Marc


 

I wanted also to briefly mention an alternative for GO exploration. Looking at the DAG for the leaf GO:0035602

one can see that the relation is actually more complicated, with multiple paths to/from GO:0006915/GO:0035602 (via GO:0042981 or not). It is possible to trace relations such as regulates, part_of with the rols package:

> childrenRelations("GO:0006915", "GO")
            GO:0043066             GO:0043065             GO:0006919 
"negatively_regulates" "positively_regulates"              "part_of" 
            GO:0043276             GO:0097194             GO:0097285 
                "is_a"              "part_of"                 "is_a" 
            GO:0042981             GO:0097190             GO:1902110 
           "regulates"              "part_of"              "part_of" 
            GO:0043280             GO:0008637             GO:0043281 
             "part_of"              "part_of"              "part_of" 
            GO:1902109             GO:1902108             GO:0043154 
             "part_of"              "part_of"              "part_of" 
            GO:1902742 
                "is_a" 
> childrenRelations("GO:0042981", "GO")
GO:0003377 GO:2001233 GO:1901692 GO:1902172 GO:2000674 GO:0043523 GO:0044532 
    "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a" 
GO:2000269 GO:0071865 GO:0033032 GO:0010660 GO:0043066 GO:0043065 GO:1902337 
    "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a" 
GO:1900217 GO:0060785 GO:1900214 GO:0043281 GO:2000351 GO:1900117 GO:2000106 
    "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a" 
GO:2000209 GO:2001053 GO:0045477 GO:0034350 
    "is_a"     "is_a"     "is_a"     "is_a" 
> childrenRelations("GO:0043066", "GO")
GO:0045849 GO:0033668 GO:2001234 GO:1902173 GO:1901693 GO:2000270 GO:0044336 
    "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a"  "part_of" 
GO:1900215 GO:1900218 GO:2000811 GO:1902338 GO:2000675 GO:0043524 GO:2000107 
    "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a" 
GO:1900118 GO:0010656 GO:0034351 GO:2000352 GO:0043154 GO:0033033 GO:0071866 
    "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a"     "is_a" 
GO:2001054 
    "is_a" 
> childrenRelations("GO:0071866", "GO")
GO:0035602 
 "part_of" 

This approach might be of interest in cases as described in the question.

Hope this help.

Laurent