Add safe profile for use when combining ontologies

[cmungall]

Use case: combine multiple linked ontologies, use RG to determine formal ancestor relationships; avoid accidentally inserting intra-ontology is-as. See: OWL is not modular

This can be done by preprocessing using robot remove with --axioms "equivalent disjoint annotation" as well as Domain and Range axioms (can't figure out how to do that in robot). It would be convenient to have this as a "graph walker" profile in RG, to avoid preprocessing. This will yield correct n-hop edges while not overwriting vetted assertions from source ontologies.

This issue may subsume:

• 127

[cmungall]

Until we have this feature in relation-graph I want to make it 100% clear to anyone using relation-graph in any kind of Monarch context that we MUST do a filtering step prior to running relation-graph.

This is the step we do in semsql:

https://github.com/INCATools/semantic-sql/blob/30a7b851263b849471213d99d5c890cdccf8b8e9/src/semsql/builder/build.Makefile#L41-L42

The reasons for this seem obscure - the entailments that you get from hp.owl differ from the intentions of the developers of that ontology. There is an ongoing discussion about the best way to resolve this, but a good general principle for everyone is that when using RG for the graph-walking use case to be conservative and never inject direct edges where they are not provided in the release of that ontology.

this rule MUST be followed for all monarch use cases

cc @matentzn @caufieldjh @dosumis

[balhoff]

@cmungall would you say it would be sufficient for this mode to filter out subclass axioms where the left side is complex, and the right side is a named class? I'm thinking of the internal whelk layer, where all equivalence axioms are translated to a pair of subclass axioms. For this OWL axiom:

X EquivalentTo (r some Y)

Whelk has:

1. X SubClassOf (r some Y) <---- important for the relation graph
2. (r some Y) SubClassOf X <---- may lead to new classification

I'm suggesting relation-graph filters out axioms like 2. Retaining 1 will avoid requiring robot relax prior to input.

[balhoff]

Using that feature would require the input ontologies to be pre-classified, however (they would need to be "base-plus" files).

[cmungall]

Yes, the assumption is that the inputs are relaxed and pre-classified

yes, to make my profile super-safe it should be extended to disallow any axiom with a complex LHS. Not sure if that can be done in robot. In any case I'd consider any ontology that did that kind of transformation prior to release to be actively hostile and permaban it from ever being included in production software. (of course transforming it internally for reasoning purposes totally fine)