Added reasoning to the creation of oeo-full.omn

[areleu]

Summary of the discussion

Related to #1124

Type of change (CHANGELOG.md)

Added

• Reasoner is called after building the full ontology

Workflow checklist

Automation

Closes #

PR-Assignee

• 🐙 Follow the Pull Request Workflow
• 📝 Update the CHANGELOG.md
• 📙 Add #'s to term tracker item

Reviewer

• 🐙 Follow the Reviewer Guide
• 🐙 Provided feedback and show sufficient appreciation for the work done

[areleu]

#1475 has to be merged first

[areleu]

Can not be inferred:

• DisjointClass: Probably some incongruent disjoint class assertion.
• PropertyAssertion: Probably some missused property in the instances.

Edit: Tried to infer Disjoint classes in Protegé and it went kaputt

[areleu]

After thinking a lot about this I am now starting to wonder if it is really necessary to provide the Disjoint class inferences as part of the ontology with full closure. Is there any example application where one would need this? I accept hypothetical examples as well.

[l-emele]

We definitely do not need every disjoint. For example, in PR #882 we added the axioms:

'typical day' 'has part' some ('time span' and ('has unit' some day) and ('has number' value 1))
'typical year' 'has part' some ('time span' and ('has unit' some year) and ('has number' value 1))

Before the mentioned PR we had only:
'typical day' DisjointWith: 'typical year'

But this example shows nicely that we sometimes need disjoints at least temporarily. In the example, the disjoint should have been deleted when the proper axioms were included.

[areleu]

We definitely do not need every disjoint. For example, in PR #882 we added the axioms:

'typical day' 'has part' some ('time span' and ('has unit' some day) and ('has number' value 1))
'typical year' 'has part' some ('time span' and ('has unit' some year) and ('has number' value 1))

Before the mentioned PR we had only: 'typical day' DisjointWith: 'typical year'

But this example shows nicely that we sometimes need disjoints at least temporarily. In the example, the disjoint should have been deleted when the proper axioms were included.

I think Disjoints are non avoidable. But I mean if we need to provide the inference of all the disjoint classses of every class (which is performed in the closure of the ontology when adding the DisjointClasses option), this is the operation that I think takes insanely long and I actually don't see any direct use case.

[areleu]

Just for everyones information:

phillord/hermit-reasoner#13 (comment)

The algorithm is by itself slow for the amount of classes we have in the ontology. So we might have to consider providing the disjoint classes by some other means i don't really know how long would the reasoning would take but I suspect it may be too much for github. So probalby we can use some internal server for that, either from Magdeburg or somewhere else.

[areleu]

We could merge this under two considerations:

• The inferred ontology is created under the name ontology-closure.owl
• We do not consider DisjointClass amnd PropertyAssertion reasoning

[areleu]

Open issues moved to #1583

[MGlauer]

I do not really understand why additional subsumptions are inferred only to be dropped by robot reduce in the next step. Am I mistaken in assuming that the aim of oeo-closure that it contains the transitive closure of the subsumption relation?

[areleu]

I do not really understand why additional subsumptions are inferred only to be dropped by robot reduce in the next step. Am I mistaken in assuming that the aim of oeo-closure that it contains the transitive closure of the subsumption relation?

I pretty much built it based on https://github.com/OpenEnergyPlatform/ontology/pull/1125/files and since reduce was getting rid of duplicate axioms just left it there. Didn't know it was also getting rid of desired inferences.

[areleu]

I removed the reduce command, seems to be woking. I looked at a couple of entities and it seems to be inferring things correctly. Some axioms seem redundant but I guess that is the point of the operation. From my side we could merge this but I really think it would be nice to have someone take a second look.

[MGlauer]

The changes seem good, the oeo-full ontology seems consistent and opens in protege. Good from my side!