Add direct inferred edges as part of loading SciGraph

[cmungall]

When loading SciGraph from an ontology import chain, we should fill in missing edges in the graph (and remove any redundancies that arise from this).

I will first add a test case that demonstrates the desired behavior.

TBD: do we force the import chain to be coherent (ie no unsatisfiable classes) prior to loading? The presence of unsatisfiable classes creates false edges.

[cmungall]

This illustrates the test case. We are using the reasoner to 'repair' a missing link between dx and cx (inferred based on the base hierarchy of e-d-c-b-a).

A call to reasoner.getSuperClasses(dx, true) would return cx, but not root (root becomes an indirect inferred superclass).

@hdietze to check algorithm, but I think it should be

For each class x
 find direct inferred superclasses, D
 find indirect superclasses, I
 find asserted superclasses, A

 for each d in D, add an edge SubClassOf(x d)
 for each a in A, if a is in I and not in D, then remove edge SubClassOf(x a)

[ccondit]

Here's what's being produced now, for the record:

[ccondit]

@cmungall - should this be a configuration option in the YAML or should every SciGraph load include this elk step?

[cmungall]

Configuration is good. In theory we may also want to plug in different reasoners (Konklude looks promising)

[ccondit]

And would it be configured on a per ontology basis or for the entire graph?

On Mon Nov 03 2014 at 1:10:20 PM Chris Mungall notifications@github.com
wrote:

Configuration is good. In theory we may also want to plug in different
reasoners (Konklude looks promising)

—
Reply to this email directly or view it on GitHub
https://github.com/SciCrunch/SciGraph/issues/42#issuecomment-61549040.

[cmungall]

For the ontology that is the root of the import chain (== graph?)

On 3 Nov 2014, at 13:13, Chris Condit wrote:

And would it be configured on a per ontology basis or for the entire graph?

On Mon Nov 03 2014 at 1:10:20 PM Chris Mungall notifications@github.com
wrote:

Configuration is good. In theory we may also want to plug in different
reasoners (Konklude looks promising)

—
Reply to this email directly or view it on GitHub
https://github.com/SciCrunch/SciGraph/issues/42#issuecomment-61549040.

---

Reply to this email directly or view it on GitHub:
https://github.com/SciCrunch/SciGraph/issues/42#issuecomment-61549551

[ccondit]

If the YAML configuration looks like

ontologyUrls:
  - http://example.org/pizza.owl
  - http://example.org/wine.owl
  - ....

Should all URLs receive the same reasoning or should it be configurable for each ontology import?

[cmungall]

As far as SG is concerned, is a set of ontologyUrls equivalent to a single Url that imports the others? i.e. does it effectively merge all axioms?

I can see cases where it would potentially be useful to have a different reasoner configured for each ontology root, so let's go with this (for Monarch we will typically have a single ontology that is an importer, but others may want the flexibility).

Just a FYI, all OWLAPI reasoners follow the import chain when reasoning

[ccondit]

At this point it loads each ontologyUrl into a separate OwlManager instance. They're only merged when they're added to Neo4j.

I'll set it up so that each root can have a different reasoner associated with it.

[ccondit]

@cmungall The unit test works correctly but when the algorithm is applied to monarch.owl it ends up adding 70,775,921 edges and removing none. Does this seem correct?

[cmungall]

The ontology may be incoherent ie it has unsat classes, any unsat class is a subclass of nothing. Need to work with ont grp in removing these. For now sg should test for incoherency and not load but we may want intermediate soln where constraint axioms eg disjoints are removed prior to reasoning.

Sent from my iPhone.

On Nov 15, 2014, at 1:54, Chris Condit notifications@github.com wrote:

@cmungall The unit test works correctly but when the algorithm is applied to monarch.owl it ends up adding 70,775,921 edges and removing none. Does this seem correct?

—
Reply to this email directly or view it on GitHub.