Feature request for future major : hide reasoner inside factory and hide factory inside entities.

[Galigator]

Hello, thank you for owlapi, the quality of your work inspire me doing better code.

Following is the description a functionality I would like to see in a future version of owlapi.

OWLFactory myFactory = manager.getOWLDataFactory(myReasoner);
OWLNamedIndividual myIndividual = myFactory.getOWLNamedIndividual( ... );

Stream<OWLClass> classes = myIndividual.types();
Stream<OWLNamedIndividual> classes = individual.equivalents();

Stream<OWLClass> classes = myClasse.subClasses();
Stream<OWLNamedIndividual> classes = myClasse.instances();

myIndividual.addClassAxiom(myClasse);
myIndividual.addObjectPropertyAxiom(myProperty, anotherIndividual);

The basic principle is to attach a reasonning system to the data factory and then hide the reasoning part. Why would I enjoy to see that ?

• I have saw the error 'myIndividual.getClass()' on so many student/intern. Learning curve could be smaller.
• At work the software lead, design an overlay to owlapi just because creation of objects and reasoning from two separate objects isn't the way he like it (with just a third of functionalities).
• In dream I have plan to create a DataFactory that provide Entity that are also ATerm objects, and another one that mirror entites in neo4j.

[ykazakov]

Interesting proposal. However, It would not be enough to add the data factory, one would have to change/extend the interfaces of OWLNamedIndividual and other OWLObjects to provide functions like types() or equivalents(). How to document these functions? The result clearly depends on the reasoner and ontology. It is like adding to the String class a method getLineNumber() to return the line in which this string appears in a text document. I am not convinced this is a good idea. Besides, how this would prevent students from mis-using myIndividual.getClass()?

[ignazio1977]

Interesting ideas but they include the fact that an OWLEntity has a reference ontology, which is a major change in the way the OWL API is currently designed. I think it would be better suited for a decorator, where we'd have a wrapper for OWLEntity that knows which ontology and which reasoner we wish to use, and simply shortcuts the common operations and their boilerplate code. That way, this would be doable without too much change.