[Bioc-devel] FW: GO offspring consistency

[Marc Carlson]

Thanks Vince,

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.

  Marc



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 
> 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.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
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel