Add get_contrastive_explanation() support in SyncReasoner + integration tests in (Feature/abduction sync reasoner)

[Balramt]

This pull request introduces support for contrastive (fact–foil) explanations in SyncReasoner, using the updated Java explanation generator. It also includes integration tests to validate end-to-end behavior with a real ontology and HermiT reasoner.
What was added :

• Implemented get_contrastive_explanation() in SyncReasoner
• tests/test_contrastive_explanation.py
• /examples/ontology_contrastive_explanation.py

[alkidbaci]

Why do you have to store them in local variables when you can use self.x directly?
Also why call getattr(self, "owlapi_reasoner", None). The owlapi reasoner is stored under self._owlapi_reasoner and is never None.

[alkidbaci]

the owlapi_reasoner is never None

[alkidbaci]

We should use the same reasoner that the user has defined (stored self.reasoner_name). For example the user may have specified Pellet but your code will default to ELK for ExplenationConfig.

[alkidbaci]

1. When I try to run the example script ontology_contrastive_explanation.py I get a java exception:

   Traceback (most recent call last):
     File "/home/alkid/PycharmProjects/owlapy/examples/ontology_contrastive_explanation.py", line 64, in <module>
       main()
     File "/home/alkid/PycharmProjects/owlapy/examples/ontology_contrastive_explanation.py", line 26, in main
       ontology = SyncOntology(ontology_path)
     File "/home/alkid/PycharmProjects/owlapy/owlapy/owl_ontology.py", line 1021, in __init__
       self.owlapi_ontology = self.owlapi_manager.loadOntologyFromOntologyDocument(File(file_path))
   java.lang.java.lang.NullPointerException: java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "parserFactory" is null
   

   This is happening when trying to initialize a SyncOntology object. The exception does not happen in the develop branch.

2. The tests are not passing successfully. Please see into that.

3. I have left you some comments in the code changes

4. Your tests only ensure type and format correctness but not what the result actually contains. For example, instead of just checking self.assertIsInstance(result["common"], set), you can also check self.assertCountEqual(result["common"],expected_result) where expected_result is a set containing the expected result.

5. Please move the methods you have implemented (get_contrastive_explanation and create_justifications) after the __init__ of SyncReasoner. Ideally you put them at the end, which indicates a natural order of implementation time.

6. Please rename the jar dependency contrastive-explanations-0.3-SNAPSHOT-jar-with-dependencies.jar (remove the "-SNAPSHOT-jar-with-dependencies" part)

[alkidbaci]

@copilot Check if all the changes requested are taken care of, otherwise open a new PR and complete them.

[Copilot]

@alkidbaci I've opened a new pull request, #174, to work on those changes. Once the pull request is ready, I'll request review from you.

[alkidbaci]

It appears that the jar dependency that you have added is overwriting some of the existing java packages.
Can you show me the source of that dependency @Balramt

[Balramt]

We do need de.tu-dresden.inf.lat.evee:evee-elk-proof-extractor-owlapi4:0.3 (OWLAPI4-based) for proof extraction.

Running mvn dependency:tree -Dverbose shows that this dependency pulls in ELK OWLAPI4 artifacts (and transitively OWLAPI 4.5.9), while the owlapy project itself depends on OWLAPI 5.x. Since both OWLAPI 4 and OWLAPI 5 use overlapping org.semanticweb.owlapi.* packages, this can lead to class shadowing when building the fat jar.

de.tu-dresden.inf.lat.evee:evee-elk-proof-extractor-owlapi4:0.3
+- org.semanticweb.elk:elk-owlapi4:0.5.0-SNAPSHOT
| +- net.sourceforge.owlapi:owlapi-api:4.5.9
| +- net.sourceforge.owlapi:owlapi-impl:4.5.9

Then contrast it with our owlapy project OWLAPI5 usage:

anonymized:contrastive-explanations:jar:0.3-SNAPSHOT
+- net.sourceforge.owlapi:owlapi-distribution:jar:5.1.20:compile

[alkidbaci]

Well I believe this is a problem with no apparent solution then. The JVM can only be started once and the dependencies are set at the moment of initiation. The conflicting distributions of OWLAPI should not coexist in the same JVM session.