[Bioc-devel] FW: GO offspring consistency
mcarlson at fredhutch.org
Fri Dec 5 19:14:55 CET 2014
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
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.
>> xx <- as.list(GOBPOFFSPRING)
>> setapt <- xx$"GO:0006915" #apoptosis
>> subsetapt <- xx$"GO:0042981" #offspring of apoptosis
>  TRUE
>> all(subsetapt %in% setapt)
>  FALSE
> Is there something wrong or are we misunderstanding the GOBPOFFSPRING object?
> Best wishes,
> 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
More information about the Bioc-devel