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
On 12/02/2014 04:29 AM, jelle.goe...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
