[Bioc-devel] FW: GO offspring consistency
mcarlson at fredhutch.org
Fri Dec 5 19:24:49 CET 2014
But actually I was planning to take this straight to the manual pages.
It's going to make for a longer manual page, but someone might find it
helpful down the line.
On 12/05/2014 10:14 AM, Marc Carlson wrote:
> 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
> 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
> 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 "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,
> 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
>> 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
> Bioc-devel at r-project.org mailing list
More information about the Bioc-devel