OWLOOP: A Modular API to Describe OWL Axioms in OOP Objects Hierarchies

OWLOOP is an Application Programming Interface (API) for using the Ontology Web Language (OWL) by the means of Object-Oriented Programming (OOP). It is common to design software architectures using the OOP paradigm for increasing their modularity. If the components of an architecture also exploit OWL ontologies for knowledge representation and reasoning, they would require to be interfaced with OWL axioms. Since OWL does not adhere to the OOP paradigm, such an interface often leads to boilerplate code affecting modularity, and OWLOOP is designed to address this issue as well as the associated computational aspects. We present an extension of the OWL-API to provide a general-purpose interface between OWL axioms subject to reasoning and modular OOP objects hierarchies.

⋆ This manuscript has been submitted to the SoftwareX Elsevier journal on the 12th of January 2021, revised on the 18th of November 2021, accepted on the 14th of December 2021, and published on the 30th of December 2021.This document contains the published version of the manuscript.Please, cite this work as: Luca Buoncompagni, Syed Yusha Kareem, and Fulvio Mastrogiovanni, "OWLOOP: A Modular API to Describe OWL Axioms in OOP Objects Hierarchies", SoftwareX, January 2022, 100952, Vol.17, Elsevier, https://doi.org/10.1016/j.softx.2021.100952.
Table 1: Code metadata

Motivation and Significance
The Web Ontology Language (OWL) is a semantic language standardised by the World Wide Web Consortium (W3C) [1].It is used to formalise implicit and explicit knowledge as logic-based axioms among symbols to represent things, groups of things, and relations between things in a domain of interest.
Ontologies provide the ability to reason on a semantic knowledge representation, which is particularly important for applications involving autonomous systems and human-machine interaction.From a software architecture perspective, an ontology is meant to be used in synergy with other software components [2], which are usually implemented with the Object-Oriented Programming (OOP) paradigm.However, issues occur since OWL axioms are not structured in an ontology following the OOP formalism.Although there are similarities between the knowledge in an ontology and OOP-based data structures (e.g., classes, objects, or properties) there are also non-trivial differences, an exhaustive list of which can be found in [3].This is one of the reasons why software developers are typically reluctant to use ontologies in their architectures [4].
As surveyed in [4], for accessing and integrating ontologies in a software architecture, the active and passive OWL to OOP mapping can be used.The active mapping transforms an ontology from its syntactic form, e.g., based on the eXtensible Markup Language (XML), to code statements in a target programming language.With an active mapping, there is the possibility of reasoning over the executable ontology at runtime [5,6,7], but this process is limited to the amount of fitness between the OWL language and its OOP counterpart.Instead, with the passive OWL to OOP mapping [4], an ontology is integrated with the OOP language through an external inference engine, i.e., a reasoner like Hermit [8] or Pellet [9], among others.The reasoner exploits the factory pattern to create immutable OOP objects containing snapshots of the knowledge in the ontology, which is an OWL-based data structure loaded in memory.
The passive mapping involves an API-based strategy, while the active mapping concerns an ontology-oriented programming strategy [4].On the one hand, the passive mapping focuses on performance but it might lead to complex and voluminous source codes.Furthermore, with a passive mapping, OWL axioms which are related to each other in the ontology are always represented as independent OOP objects.Therefore, passive mapping allows to use OWL axioms through OOP objects but it does not exploit the benefits of the OOP paradigm as active mapping does.On the other hand, we are not aware of an active mapping that supports all the reasoning mechanisms implemented by the OWL reasoners used with passive mapping.
To develop a software architecture exploiting the OWL formalism, we identify two aspects concerning the design and implementation of (i) the OWL-based knowledge representation from data and prior semantics, and (ii) the interfaces among the components of the software architecture and OWL-based knowledge.The former aspect can be tackled with different ontology design patterns1 , which can be implemented using available tools, e.g., OWL-API [10], Jena-API [11] or the Protégé editor [12].These tools exploit string-based identifiers of OWL symbols, and they allow to define the procedures that retrieve specific knowledge through queries.Although these tools support well the ontology design process, they might not be suitable for the latter aspect since it has different requirements, which include modularity, maintainability and synchronisation of the software architecture.Both aspects might be tackled by developers with different expertise, i.e., on OWL formalism and software architecture solutions, respectively, and they require a constant joint effort to develop an effective system.Thus, we aim for an API which can be used to develop a modular abstraction layer interfacing ontologies and software components.In our approach, on the one hand, experts on OWL ontologies can design semantic data representation and store it in a file as prior knowledge; also, they can develop OWLOOPbased interfaces to manipulate and query the ontology at run time.On the other hand, the ontology and OWLOOP-based interfaces can be used by the developers focusing on architectural aspects through the OOP paradigm.
This paper presents the OWLOOP API, which implements a passive OWL to OOP mapping for integrating ontologies and software architectures.We aim to entirely support OWL reasoners and exploit the benefits of the OOP paradigm by avoiding the factory design pattern.The OWLOOP API interfaces OWL axioms with descriptors, which are OOP classes representing a fragment of the ontology, but they are neither immutable nor independent.In other words, descriptors can be designed within an OOP-based hierarchy of classes.OWLOOP supports the implementation of general-purpose and modular OWL to OOP mapping, which can improve flexibility, reusability and maintainability of software architectures exploiting ontologies.

OWL Formalism Overview
Figure 2 depicts an ontology used as an illustrative example throughout the paper.An OWL ontology is made by axioms, i.e., symbolic statements de-scribing some entities (listed in Table 2) with a specific logic-based semantic expression.Axioms are organised in three structures, i.e., the Terminological and the Rule graphs (TBox and RBox), and the Assertion set (ABox).
The TBox describes concepts (OWLClasses or classes in short) as a hierarchy of logic implications (e.g., a ROOM is a sub-class of LOCATION) with the THING class as default root, i.e., the super-class of all possible classes, and its counterpart NOTHING.Instead, the ABox collects instances (OWLNamedIndividual or individuals) of concepts, e.g., Room1 is an instance of the ROOM class, which could be related among each other through roles (or properties), e.g., Room1 isLinkedTo Corridor1.The RBox represents properties and sub-properties similar to the TBox, and it includes specific definitions, such as transitive, symmetric, etc.A property in the Rbox can describe its inverse property, and its range and domain classes, e.g., hasDoor relates instances of LOCATION and DOOR classes, respectively.OWL standard distinguishes object properties from data properties; OWLObjectProperty and OWLDataProperty, respectively.As introduced above, the former relates two individuals, while the latter relates an individual domain with a literal (OWLLiteral) range, e.g., a number.A literal is considered as an instance of concrete classes (OWLDataTypes), e.g., the set of positive numbers.
OWL defines the logic disjunction and conjunction among classes, as well as cardinality restrictions to represent classes through properties, e.g., a CORRIDOR is a LOCATION that has (i.e., hasDoor) at least 2 Doors.In addition, each pair of entities within the same box can be set to be equivalent or different (i.e., disjoint), e.g., Robot1 is a different individual from Room1.The axioms in the three boxes of the ontology can be processed by OWLbased reasoners, which check the consistency of an ontology and infer new implicit axioms under the open word assumption.In addition, it can solve queries that are given as incomplete axioms, e.g., find all instances of the ROBOT class.To better appreciate the reasoning ability, more details of the OWL formalisms are available in [13,14].
To deal with such a variety of axioms semantics, the standard implementation of OWL associates each axiom A j to a certain k-th expression E k , e.g., Sub, Super, Instance, Equivalent, Disjoint, etc.In turn, the expression defines the types of entities that need to be specified in the axiom A j = E k (e 1 , e 2 , . ..), e.g., the sub-class expression requires that e 1 and e 2 are both classes, while the instance expression requires an individual and a class.To represent axioms suitably for OOP mapping, OWLOOP provides an E k counterpart for each OWL expression, e.g., an OWL ObjectPropertyAssertion is an OWLOOP ObjectLink, while an OWL ClassAssertion is an OWLOOP Type.This paper presents OWLOOP expressions as shown in Table 3 and introduced above, e.g., some OWL axioms in our illustrative ontology are The OWLOOP API enables interaction with OWL entities in an ontology by using descriptors, i.e., Java classes encapsulating reusable code to exploit OWL axioms, e.g., string-based identifiers of OWL symbols and procedures based on queries.The next Section presents the structure of OWL axioms in a descriptor, while Section 2.3 focuses on the descriptor functionalities to assert and retrieve knowledge subject to reasoning.

Software Architecture
The OWL to OOP mapping implemented by OWLOOP stores the axioms involving an E k expression into a data structure (2) Each i-th element of the entity set Y k is an OWLOOP entity, which can either be an OWL entity (as in D 1 and D 2 ) or a structure of OWL entities, i.e., as specified in Table 2, an OWLOOPObject (in D 3 ), an OWLOOPData (in D 4 ) or an OWLOOPRestriction (in D 5 ).
OWLOOP represents the data structure D in the OOP interface named Descriptor, which is implemented as shown in Figure 3 through the Unified Modelling Language (UML), whose notation is summarised in Figure 1.From (2) it is possible to deduce that descriptors with the same type of ground might be merged to encode different axioms, e.g., D 1 and D 2 can be represented in a compound descriptor  Table 3: The expressions that OWLOOP can currently map into axioms (in the second column), organised by the four types of descriptors, i.e., class, individual, object and data property descriptors.The type of each descriptor is given by the type of its ground entity (in the first column), and it can describe the shown expressions, each with a specific entity set (third column).In order to address an application, developers should design suitable compound descriptors with sets of axioms based on Table 3.Four steps should be followed to design a compound descriptor based on the functionalities that an OOP class can inherit from OWLOOP interfaces, e.g., as shown in Listing 4: (i) assign a ground entity by inheriting from one of the interfaces provided by the ⋆ .descriptorGroundpackage; (ii) inherit from extensions of the Descriptor interfaces (available in the package ⋆ .descriptorExpression) the representation of some expressions E k ; (iii) consistently for each E k expression, instantiate an empty entity set based on the ⋆ .descriptorEntitySetpackage; (iv) for each E k , specify a descriptor to build (addressed in the next Section).
Figure 4 shows the implementation of the FullClassDescriptor, which is a compound descriptor involving all the class expressions shown in the first row of Table 3.
Therefore it requires as EntitySet four sets of Classes, a set of Individuals and a set of Restrictions.Remarkably, any compound descriptors with a ClassGround that can be implemented with OWLOOP concerns a subset of expressions involved in the FullClassDescriptor.
Figures 5 and 6 respectively show the implementation of the FullIndividualDescriptor, and the FullObjectPropertyDescriptor, from which it is possible to derive the implementation of the FullDataPropertyDescriptor.Indeed, since our mapping exploits the same structure D for all OWL axioms, OWLOOP always relies on the same pattern to address different OWL expressions.Thus, OWLOOP is modular, and this also facilitates the implementation of the OWL axioms not considered in the current version, as discussed in Section 5.

Software Functionalities
A descriptor derived from Table 3 can be instantiated given (i) a ground, i.e., the identifier to an OWL entity (e.g., "Corridor1"), and (ii) the reference to an ontology as required by aMOR2 , i.e., an OntologyReference.For instance, Listing 1 shows at Line 1 a function to create the ontology with an associated reasoner, which should be manually invoked.As an example, Line 7 constructs a LinkIndividualDescr, which is a compound descriptor grounded on Corridor1 and it is concerned with the expressions E k inherited from the descriptors addressing ObjectLink and DataLink.More generally, an OOP interface D that extends Descriptor for an expression E k inherits the OOP methods addressed in the following paragraphs.These functionalities are based on the internal state of a descriptor (i.e., the ground x and the entity set Y k ) that can be synchronised with the ontology.A compound descriptor is an OOP object cd realising some Descriptor interfaces, whose functionalities can be accessed with cd.E k .For instance, the interfaces implemented by the object cd returned at Line 7 are accessible  D.getGround(): This method returns the ground entity x.For a compound descriptor, cd.E k .getGround()returns the same entity for all the implemented expressions E k .
D.getEntities(): It returns the entity set Y k associated to the E k expression.To enable the definition of compound descriptors, each descriptor D defines this method with a different name, e.g., cd.getObjects() for the ObjectLink expression, and cd.getEquivalentIndividuals() for Equivalent associated to an individual ground.These methods are used to access entities y i , as well as manipulate them, e.g., through cd.removeObject().
D.query(): This method returns the knowledge related to the k-th expression that involves the ground entity in the ontology.It returns a set structured as Y k but it does not affect the internal state of the descriptor.It is mainly used by the Descriptor interface itself.
D.readAxioms(): It relies on D.getEntities() and D.query() to compare the internal state of the descriptor with the state of the ontology.It changes the entity set of the descriptor to be equal to the ontology.It returns a list of intents containing all the performed changes, which can be used to recover from possible inconsistencies.A compound descriptor provides the method cd.readAxioms(), which invokes cd.E k .readAxioms()for each k-th expression concerned by cd.D.writeAxioms(): It is similar to readAxioms() but it changes the  ontology to become equal to the entity set.D.build(): It allows to use a descriptor in an OOP manner since it returns a new compound descriptor nd grounded in each entity y i .While designing compound descriptors, developers should specify the type of nd with a ground consistent with the elements in the entity set of D. Then, the entity set of the new descriptors is populated through the nd.readAxioms() method.Similarly to D.getEntities(), each descriptor D defines building methods with different names to enable the definition of compound descriptors.Remarkably, if entities y i are not OWL entities, the build() method would have multiple definitions, e.g., for an ObjectLink it is possible to return descriptors nd grounded on an object property or on an individual.
There are also other useful functionalities implemented by aMOR, e.g., to get OWL entities or save the ontology.Moreover, the function ontoRef.synchroniseReasoner()performs OWL reasoning, which involves all the OWL expressions.Remarkably, OWL querying is a time-consuming task if reasoning is required.Hence, the reasoning process should only be used when required, i.e., to affect the results of query() and, consequently, the outcomes of readAxioms() and WriteAxioms().In addition, to be compatible with other software using ontologies, aMOR provides full access to factory-based OWL to OOP mapping implemented with OWL-API.

Asserting and Inferring OWL Axioms
Listing 2 shows how to use compound descriptors to manipulate an ontology by adding and removing some of the axioms shown in Figure 2. At Line 13 the axiom ObjectLink(isLinkedTo, Corridor1, Room1) is added to the relative entity set, and the same operation is performed at Line 14 with a different type of input.At Line 15, the ontology changes such that Corridor1 is linked to Room1 and Room2.Lines 18-19 define axioms concerning disjoint classes, and at Line 20, the ontology is changed to contain them, i.e., Disjoint(ROBOT, LOCATION) and Disjoint(ROBOT, DOOR).Lines 23-24 add axioms to specify the domain and range of the hasDoor property, i.e., Domain(hasDoor, LOCATION) and Range(hasDoor, DOOR), which are applied to the ontology at Line 25.
Line 27 updates the reasoner to infer new knowledge in the ontology, which is then synchronised with the internal states of the descriptors at Lines 28-30.By reading axioms, we can populate the entity set with implicit knowledge required for implementing procedures that are based on queries.Finally, Line 32 shows a way to remove an element from the internal state of a descriptor, and Line 33 applies those changes to the ontology.Listing 2: Example showing how to manipulate axioms through descriptors.

Accessing OWL Axioms with the OOP Paradigm
The example in Listing 3 has the objective of finding the type of room where the robot is located, e.g., CORRIDOR.The example shows the retrieval of the individual related to the isIn property, e.g., Corridor1, that we store in a variable named robotLoc.Then, it shows how to find the OWL classes that classify robotLoc such that they are a leaf in the TBox.Within Lines 37-40 the robot location is retrieved by assuming in the ontology that only an isIn axiom involving Robot1 exists.Lines 42-44 initialise a descriptor grounded on robotLoc that maps OWL classes concerning the Type expression.Line 48 builds the Type of robotLoc, i.e., it computes a set of descriptors that are grounded in a class representing the robot location (e.g., CORRIDOR, LOCATION and THING), and involving Sub expressions.For each class of robotLoc, Line 54 checks whether it has only one sub-class, i.e., NOTHING, which implies that it is a leaf class in the ontology.
sub-classes in an OOP fashion, and a similar approach can also be used for the other expressions.In particular, at Lines 48-58, we iterate for each individual to retrieve their class and related sub-classes without using the OWL factory but only relying on the OOP-based internal states of the descriptors.This is possible thanks to the build() method since it can be used to relate entity sets of different descriptors and, as an example, Lines 40-44 show a possible implementation of it.However, to retrieve locIndiv from robot1 directly through building, the descriptor LinkIndividualDescr should have been designed to build new individual descriptors concerning the Type expression, while it builds descriptors concerning ObjectLink and DataLink expressions, i.e., other LinkIndividualDescr.
A simplistic approach could be to always build full descriptors for accessing all possible expressions from each build() method, but this might impact computation complexity since OWLOOP would synchronise axioms that might be unnecessary.

Compound Descriptor Implementation
In order to highlight the modularity of OWLOOP, Listing 4 shows the implementation of a ClassDescriptor that inherits the functionalities listed in Section 2.3 for two types of expressions, i.e., Instance and Sub.Indeed, for all the Descriptors based on Table 3, the same pattern can be used to implement OOP classes encoding OWL knowledge, and that are related among each other based on the ontology, e.g., it is possible to get or set the individuals or the sub-classes of the ground class in an OOP-like manner.In particular, the get or set entities are not encoded in immutable classes as in the case of the factory design pattern but in OWLOOP descriptors, which can be related to other descriptors through the building methods.
In addition, a developer can exploit OOP-based polymorphism to implement a hierarchy of OWLOOP descriptors, which encode string-based identifiers of OWL symbols and procedures to retrieve implicit knowledge based on OWL reasoning in a modular way.Hence, experts on OWL formalism can build an abstract layer concerned with OWL-related aspects by the means of descriptors, which can be provided to experts in software architecture who aim to use an ontology within an OOP-like paradigm.
For example, Listing 3 could be implemented as a method of the descriptor in Listing 4. In this way, experts in software architectures may rely on an OOP-like method to retrieve the robot position and, at the same time, OWL-formalism experts may exploit a modular interface to the ontology for representing knowledge about the robot position.

Impact
OWLOOP enables the implementation of modular OOP hierarchies of descriptors that represent specific knowledge in the ontology.Descriptors can encode both string-based identifiers of OWL symbols, i.e., immutable OOP objects, and procedures to exploit implicit knowledge based on polymorphism and OWL reasoning.Since descriptors can build other descriptors such that they are related to each other based on the ontology, it is possible to exploit OWL-based knowledge through OOP objects that are mutable.Moreover, the process of adapting a system when its ontology changes is simplified with OWLOOP because all OWL-related aspects are encapsulated in the descriptors rather than being defined by software components.Hence, OWLOOP allows to decouple the OWL-based representation of knowledge and its usage within a software system.
OWLOOP is based on aMOR, which is a library providing utilities to use OWL-API.Since aMOR does not hide the access to OWL-API, developers can keep using any procedure based on OWL-API.However, other OWLbased APIs (e.g., Jena) enable working with different ontology formats, which are currently not compatible with OWLOOP.Nevertheless, there is no reason for which our OWL to OOP mapping cannot be implemented with other APIs that encompass the OWL formalism.In addition, other available tools can be used to design an ontology that can be later interfaced with the components of software architectures using OWLOOP descriptors.Indeed, within the OWL public class CDescr extends ClassGround domain, there are no particular features that OWLOOP tackles but other tools do not.Nonetheless, in the domain of software design, development and maintenance, OWLOOP has features that are not directly provided by other OWL-related APIs, especially when reasoning is concerned.In particular, OWLOOP descriptors can inherit and extend procedures to evaluate axioms in an ontology by hard-coding only a few string-based identifiers of OWL symbols.Also, through the building methods, descriptors can access a piece of knowledge without explicitly using any farther axioms.
Ontologies have been used in a large range of applications, e.g., concerning semantic web [15], data access [16], information retrieval [17], medical knowledge representation [18], internet of things [19], robotics [20], and ambient assisted living [21].Usually, OWL ontologies are deployed in software architectures by assuming that they only contain knowledge that does not change over time.Other systems exploit ontology structures where individuals are dynamic, while classes and properties are static.However, some applications also require changing OWL classes over time, e.g., to learn scene classification from images [22].In that work, which has been deployed in a software architecture to address human supervision [23], and to classify scenes in a long-term interaction [24], we observed that OWLOOP allows to develop a more modular architecture than OWL-API since it can decouple the procedures related to the knowledge representation and its deployment.For complex systems involving a robot, OWLOOP has been integrated4 in the aRMOR service [25], which allows to use ontologies in the Robot Operating System (ROS).Furthermore, by investigating the problem of human activity recognition [26], we observed that OWLOOP is efficient for system prototyping and evaluation of activity models designed by domain experts.

Conclusions and Future Work
OWLOOP API performs a passive OWL to OOP mapping that allows to use knowledge inferred from OWL reasoners within the OOP paradigm.We presented OWLOOP descriptors, which are modular Java classes interfacing a hierarchy of OOP objects with the knowledge structured in memory as an ontology.Descriptors enable designing general-purpose interfaces between ontologies and components of software architectures such that drawbacks in the computation are avoided.In addition, they encapsulate boilerplate code to simplify the development and maintenance of an architecture.OWLOOP is compatible with other tools to design ontologies, and it is suitable for integrating dynamic ontologies within complex software architectures.
The current version of OWLOOP concerns only the expressions shown in Table 3, which do not encompass the whole OWL axioms.For instance, it cannot represent classes through structured disjunctions and conjunctions of class restrictions as defined by OWL.Instead, it considers all the restrictions to be in conjunction without a specific order.This is not a limitation for all the applications where the definition of OWL classes do not change dynamically, because the ontology can be created with other tools and be interfaced with OWLOOP afterwords.Although there are no reasons for which our OWL to OOP mapping cannot consider all OWL axioms, we present this preliminary implementation to propose our approach.Nevertheless, in the future, we want to modularly extend OWLOOP to support all OWL axioms by designing new types of OWLOOP entities and related descriptors.

Figure 1 :
Figure 1: The UML notations used in this paper.

Figure 2 :
Figure 2: A simple ontology used as an example throughout the paper.

Figure 3 :
Figure 3: The general-purpose definition of OWLOOP Descriptor.Colours identify OOP packages, which are also consistently used in Figures 4-6.

Figure 4 :
Figure 4: The implementation of the FullClassDescriptor.

Figure 5 :
Figure 5: The implementation of the FullIndividualDescriptor.

Figure 6 :
Figure 6: The implementation of the FullObjectPropertyDescriptor.
where Y 1 and Y 2 concern the Super and Instance expressions.Hence, OWLOOP provides four different descriptors based on their ground, i.e., ClassDescriptor, IndividualDescriptor, ObjectPropertyDescriptor, and DataPropertyDescriptor.

Table 2 :
On the left-hand side, the possible types of entities in an OWL ontology.OWLOOP entities can either be OWL entities or structures of OWL entities, which are shown on the right.The cardinality C spans in an OWL axiom among {some, only, min n, max n, exact n} where n ∈ N + .