Multiple Issues regarding the current implementation of the FaCT++ reasoner.

Dear EMMOntopy developers,

I hereby would like to report a possible bug and a selfimplemented solution, I could come up with, for the reasoning with FaCT++ provided via your ‘factpluspluswrapper’. I am a chemical engineering Ph.D. student, working with the german NFDI4Cat, and, as my branch of studying indicates, not necessary skilled in finding a programmers solution, but only an engineer’s solution, to a coding task. As such, my report is the best I could come up with, given my knowledge of reporting such a bug. As I am interested in working with the python implementation of the FaCT++ reasoner, and found it not to be working on my PC’s , I tried finding a solution to my issues, and will try to explain them as best as I can. If any questions occur or you just want to contact me, feel free to write me via hendrik.borgelt@tu-dortmund.de. An online-meeting (e.g. ZOOM-call) can be arranged if the descriptions are not conclusive.

1. Issue (temp.NamedTemporaryFile instead of temp.TemporaryDirectory):

Running the base code provided by you on GitHub or via the direct installation via pip results for me in a ‘PermissionError’. I could trace it back to be a path of a temporary file handed over to graph.serialize, instead of a temporary dictionary, which it requires instead. A detailed logging of the error can be found in the supplement file called ‘Log1_TempFileVsTempDir.txt’.

I solved this error by changing from a NamedTemporaryFile to a TemporaryDirectory as given in the code snippet below:

The commented code is the original code, while my implemented code of the ‘reason’-function is the active code, I manipulated. The ‘reasoning’-function is contained within the ‘owlapi_interface.py’

2. Issue (Java exception in ‘main’ no FaCTPlusPlusJNI in java.library.path):

The second error message I got after fixing the first one, was a missing java package for with the detailed error Message can be found in ‘Log2_AddedFaCTppJavaFiles.txt’. As a quick search through the common search engines revealed, the given files, specifically ‘libFaCTPlusPlusJNI.so’ In path ‘.\ontopy\factpluspluswrapper\java/lib/so’ should suffice to start the reasoner. However, I knew of problems with Protégé and FaCT++ (https://github.com/emmo-repo/EMMO/blob/master/doc/installing_factplusplus.md, thanks for this wonderful help), I ‘gu’-estimated that one of the files might not be correct/sufficient for running the reasoner. Therefore, I copied the content contained in the respective directory of Protégé into the directory of ontopy, in hopes of fixing the error in a trial-and-error fashion. This solved at least the raised exception, even though I do not know if the approach is valid. Both, the original content (directory: ‘Original files’), as well as the new content (directory: ‘MyFilesFromProtege’) can be found in the ‘Zip’-file appended to this mail.

3. Issue (Handling of rdfs:type inside sync_reasoner_factpp):

Executing the ‘sync_reasoner(reasoner="FaCT++")’-function, finally works without an escape-exception. However, the debugging tool can not find the parent ‘11’, which is the implemented class abbreviation for ‘OWL.Class’ as implemented in ontopy/owlready2. The logging results of reasoning the EMMO as found on ‘https://emmo-repo.github.io/’ in its compacted format (https://emmo-repo.github.io/versions/1.0.0-beta4/emmo.owl) with FaCT++ can be found in ‘Log3_WrongHandlingOfRdfsType.txt’. Searching in the code of ‘sync_reasoner_factpp’ and ‘owlready2.reasoning.py’ for a solution to this problem, I found out that the parenting method (‘new_parents’) does not allow for ‘rdfs_classes’, while they should occur in ‘entity_2_type’. As the method used in sync_reasoner_factpp() does however misclassify several classes and properties to individuals I tried to find the root cause. It presented itself to me as a misinterpretation of the ‘rdfs:type’ predicate, which misclassified several ontology objects as being ‘Individuals’ by interpreting them with ‘OWL_2_type’. Therefore the abbreviated triple ‘EMMO (isof)type Class’ would result in the EMMO-class being misidentified as an individual. To solve this misinterpretation, the for-loop used to evaluate the results was rewritten as well as a new classifier written. The new code can be found in the Zip-file and is called ‘sync_factpp_borgelt’. With these implementations done, the result of the reasoner comes pretty close to the results achieved by using HermiT with python or HermiT and Fact++ with Protégé (all of them are slightly different to oneanother).

4. Remarks (some complex properties might be handled as simple properties):

As I am not familiar with any benchmarking tools to compare reasoning results for correctness, I can only validate, that the results are similar to those performed by reasoning with Protégé as well as with HermiT on python. A further reasoning with Protégé, in order to validate that no consistency error was introduced by the reasoning with the self-(gobbled-/) implemented FaCT++ fix, yielded a consistent ontology. As the results of reasoning with the ‘fixed’ FaCT++ reasoned yield the possibility for further improvements(/possibly mandatory) work, I would like to point out the ‘Special_ReasoningResults.txt’-file, in which some of the complex property relations are listed, and the ‘Results_from_graph_containing_rdfs_type.txt’-file, in which all results are listed. As complex properties such as ‘IrreflexiveProperty’ are only handled as simple ‘ObjectProperties’ be the ‘entity_2_type’ converter, further work might be required. Also, some ‘subject’-handles such as ‘rdflib.term.URIRef('http://www.w3.org/2004/02/skos/core#hiddenLabel')’ might be required to be handled different from the current implementation provided by me.

I hope that the comments and suggestions, I have tried to conclude above, are of use to you and I would like to emphasize once again that I am happy to answer any questions.

With kind regards Hendrik Borgelt FaCTpp_wrapper_bug_report_with_fix_recommendation.zip

emmo-repo / EMMOntoPy