LEGO GAF/GPAD October 5, 2016

From GO Wiki
Jump to: navigation, search

Bluejeans URL:


Review Existing github Tickets and Prioritize

In some ways it's easiest to get it all right first time round, but as a way of stratifying the work, doing it in this order

1. agreeing on the basic property chain rules that should be encoded in RO. DOS - could you give an update of the most recent changes to RO?
2. deciding on policy for inferred evidence where the inference includes >1 piece of evidence
3. Additional ad-hoc procedural rules, such as whether to filter or include root nodes (#60)
4. Provenance, and ensuring the assigned-by field is correct

Although in some ways 1 is the hardest, from a CS POV it's the cleanest. If we can agree on this and just use inference to produce the core GPAD triple, we're most of the way there (of course, the plumbing required for inference is annoyingly hard, Jim could give an update of some of his thinking here, but that's more of interest to DOS).

DavidH, I added some comments here: I don't think involved in is correct, maybe DOS could comment?

Good example though!

I also added another example, for a more straightforward case that doesn't require any transitivity reasoning

This is an example of one that would produce the correct GPAD (I believe) using the existing structural transformation rules that Heiko implemented. But moving forward, for cases like 59, we will need at least some minimal property chain reasoning.


  • Jim has spent time working on the reasoner to see what all of the inferences will be and how it would look if displayed in the graphical reasoner
    • Reasoner generates all relations, including the inverse relations
    • Inverse relations will likely not be needed for GAF/GPAD because these files represent information in one direction only (GP -> GO term)
    • Inverse relations might be useful for queries, though
  • Run models through the current GAF/GPAD exporter to see what we get
    • The current GAFs/GPADs are quite limited, without many inferences
  • Found that terms without IDs could be entered into a field, but put checks in place to prevent this in the future