Pascal Zaragoza

Abdelhak-Djamel Seriai

Abderrahmane Seriai

Hinde-Lilia Bouziane

Anas Shatnawi

Mustapha Derras

Refactoring Monolithic Object-Oriented Source Code to Materialize Microservice-oriented Architecture

Keywords: Microservices, Monolith, Modernization, Reverse Engineering, Refactoring, Software Architecture

The emergence of the microservice-oriented architecture (MSA) has led to increased maintainability, better readability, and better scalability. All these advantages make migrating a monolithic software towards an MSA an attractive prospect for organizations. The migration process is recognized to be complex and consequently risky and costly. This process is composed of two phases: (1) the microservice-based architecture recovery phase and (2) the transformation (i.e. materialization) phase. In this paper, we propose a systematic approach to transform an object-oriented monolithic application towards an MS-oriented one by applying a set of transformation pattern. To validate our approach we automated it with our tool MonoToMicro, and applied it on a set of monolithic Java applications to be migrated towards microservices-based ones.

INTRODUCTION

The microservice-oriented architecture (MSA), with its capabilities for quick deployment, better scalability, and maintainability, is a recent architectural style that has appeared to take advantage of the Cloud [START_REF] Richardson | Microservices Patterns[END_REF]. MSA allows the development of applications as a suite of small services, each running in its own process and communicating through lightweight interfaces [START_REF] Lewis | Microservices: a definition of this new architectural term[END_REF], [START_REF] Newman | Building microservices: designing fine-grained systems[END_REF]. Individually, each microservice can be technologically independent, functionally autonomous while guaranteeing its autonomy with regard to their manipulated data. As a consequence, this results in a more manageable codebase as each microservice can be managed by a smaller team [START_REF] Baskarada | Architecting microservices: Practical opportunities and challenges[END_REF].

In contrast, the monolithic architecture style involves building the server-side application as a single logical executable unit (i.e. monolith) [START_REF] Lewis | Microservices: a definition of this new architectural term[END_REF]. These monoliths can become quite large and complex and thus harder to maintain. Furthermore, a change to a small part of the application requires rebuilding and redeploying the entire monolith [START_REF] Soldani | The pains and gains of microservices: A systematic grey literature review[END_REF]. When deployed and running, increasing workloads requires duplicating the entire application. This is a very resource-intensive, as every part of the application must be replicated even though all of the application is not needed [START_REF] Selmadji | From monolithic architecture style to microservice one based on a semi-automatic approach[END_REF].

This paradigm shift from the monolithic style to the MSA-based one resulted in a demand for migrating these monolithic legacy systems towards an MSA. This migration process includes: (1) the recovery of a MSA-based architecture of the existing application, (2) the transformation of the monolithic source code to be conforms to MSA principles.

Many approaches have been proposed to address the first phase of the migration process by partitioning the OO implementation of a given monolithic application into clusters of classes that can be transformed and packaged as microservices in the second phase. Although the resulting clusters help understand the target MSA, the source code must be transformed to conform to the MSA style (service-based, messageoriented communication, etc.).

The goal of the second phase of the migration is to transform the monolithic source code to create runnable microservices that conform to its target MSA, while preserving the business logic of the application. In the case of OO applications, the primary difficulty is to transform the OO dependencies between the clusters of classes into MSA ones. These transformations must adhere to refactoring principles (i.e. preserve the business-logic) without degrading the performance. However, despite the importance of the second phase of the migration (i.e. costly and error-prone), and to the best of our knowledge, no approach to automate this phase has been proposed.

In this paper, we propose a systematic approach to transform an OO application from the monolithic style to an MSA one based on a set of transformation patterns. This set of transformation patterns create microservice-based communication mechanisms that preserve the semantic of the monolith while conforming to the principles of the MSA (e.g. message-based and data-oriented). Furthermore, we propose an automated process, and a tool, that applies our systematic transformation approach. Finally, we apply our approach on a set of monolithic applications to determine whether this approach is able to refactor the code while preserving the business logic and not negatively affect the performance of the application.

MATERIALIZING MICROSERVICES FROM AN OBJECT-ORIENTED APPLICATION

The overall objective of migrating a monolithic application is to produce structurally, behaviorally, and operationally valid microservices. Particularly, we define a microservice as one that follows the commonly accepted definitions which include structural and behavioral characteristics such as "small and focused on one functionality", "structural & behavioral autonomy", and "data autonomy" [START_REF] Lewis | Microservices: a definition of this new architectural term[END_REF]. Additionally, operational characteristics include "running on its own process", "communicate with lightweight mechanisms", and "automatically deployed" [START_REF] Lewis | Microservices: a definition of this new architectural term[END_REF]. The structural and behavioral characteristics are often used to guide the recovery of the architecture. While the operational characteristics cannot be used to guide the recovery of the microservice-oriented architecture, they can be used to guide the transformation phase.

The migration of a monolithic application towards a MSA is a process that can be divided into two phases: (1) microservice architecture recovery from an OO monolithic source code and (2) the transformation of the monolithic source code towards the MSA.

Motivating Example: Information Screen

To better illustrate the problems we face during the migration process, we use throughout this paper an illustrative example of a display screen management system (e.g. an information panel in an airport). It is composed of the DisplayManager class that is responsible for handling the information to be displayed on the Screen class (see Fig 1). It does so through a Con-tentProvider class that implements methods for stacking content such as incoming messages (i.e. Message instances) or the current time (i.e. Clock instances). Finally, The Clock class uses an instance of the Timezone class to get the time based on its GPS location.

Microservice-based Architecture Recovery

This migration phase aims to decompose the classes of a monolithic application into clusters which will form the basis of a structurally and behaviorally valid microservice. Existing approaches propose different clustering techniques to maximize the quality of the microservices by maximizing the cohesiveness of the classes within a microservice while minimizing the coupling between microservices.

Figure 2 shows the results of applying a microservice recovery approach on the "Information Screen" system presented as motivating example. The recovery identifies 5 clusters, where each cluster contains one or more classes. In our example, the microservice candidate MS1 is responsible for managing the display of various content on a screen, through its classes DisplayManager and Screen. A cluster is composed of two types of classes: internal and edge classes. An internal class is a class which does not contain any dependencies with classes belonging to another cluster (e.g. Screen and GpsLocation). On the other hand, an edge class is a class which contains at least one dependency with a class from another cluster. These dependencies can be of any type (e.g. method invocation, constructor calls, or inheritance).

Transforming OO Source Code towards an MSA One

The transformation phase involves materializing the identified MSA from the architecture recovery phase. It involves transforming object-oriented source code towards a MSA one. During this phase, each recovered cluster of classes is placed into its own microservice (i.e microservice encapsulation). However, edge classes (e.g. DisplayManager, Clock), by definition, contain dependencies towards a class belonging to another cluster. These direct structural dependencies between the classes of different microservices are called microservice encapsulation violations. Before a microservice can be fully encapsulated, all violations must be resolved through refactoring methods which transform all OO-type dependencies into MS-type ones.

In this phase, we focus on the operational characteristic of an MSA to use message-oriented communication between different microservices. I.e., all procedural calls between classes belonging to different clusters (e.g. the method calls between DisplayManager and ContentProvider) must be restricted to a set of provided and required interfaces that define both the web services it provides and those it consumes. Furthermore, in an MSA, inter-process communications (IPC) calls are limited to value-based communi-cation. I.e., only primitives and serialized data may be exchanged between microservice. However, a procedural call may pass object references between the invoking object and the invoked one. To fully encapsulate microservices, the mechanism of instance sharing between microservices must be resolved.

Beyond procedural calls there are other implicit dependencies between clusters that must be addressed to fully encapsulate the microservice candidates. The main OO mechanism that must be addressed is the inheritance mechanism. An inheritance violation appears when a class and its super-class are placed in different clusters (e.g, between Message and Content).

Lastly, operational characteristics of a microservice in which it must run on its own process and be deployable automatically, require an additional task of transformation. To conform to these two characteristics each microservice must be defined in their own independent project and they must be configured to generate their own deployable image. Both of these tasks must be addressed after each microservice have been properly encapsulated. In this paper, we focus on the code transformation phase that takes place after recovering the MSA.

MONOTOMICRO: A SEMI-AUTOMATED REFACTORING APPROACH

The goal of this approach is to transform an existing monolithic object-oriented source code to a MSA one by encapsulating the clusters identified in the first migration phase. To do so, we define a process composed mainly of four steps as presented in Figure 3. These steps include: (1) detecting encapsulation violations, (2) healing encapsulation violations, (3) packaging microservices and (4) deploying and containerizing microservices.

Step (1) involves detecting encapsulation violations that occur between clusters of classes which contain OO-type dependencies (e.g. instance creation, method invocation, and inheritance) to classes belonging to another cluster. These violations must be detected before they can be resolved. For each encapsulation violations, detection rules are defined and applied on the clusters.

In step (2), "Healing encapsulation violations", a set of transformation patterns is applied to the identified violations. As certain transformation patterns would create different additional violations, a transformation order is required to resolve all violations. Next, in step (3), the violation-free microservices are packaged. To this end, a project is created for each microservice where the source code is generated. Then, the file structures and project dependencies are generated automatically.

Finally, in step (4), the microservice projects are containerized by generating instantiable images. For each microservice, an image description file is generated. In addition, a composition file is generated, which organizes and deploys all the microservices together.

In this paper, we focus on the first two steps of the transformation phase which contain the main scientific obstacles mentioned previously. More precisely, we focus on proposing a systematic approach to transform an OO application from the monolithic style to an MSA one, a set of transformation patterns, and an automated process that applies our systematic transformation approach. In Section 4, we present our first contribution, our approach to systematically detect microservice encapsulation violations. In Section 5, we present our second contribution for systematically healing microservice encapsulation violations through the use of transformation patterns. We leave the last two steps of the transformation phase for the implementation and we describe them in the section 6 along with the experimentation.

DETECTING MICROSERVICE ENCAPSULATION VIOLATION

To materialize the recovered microservice candidates from the source of object-oriented software, each recovered cluster of classes is encapsulated in its own microservice. However, upon encapsulation, OO dependencies between clusters are no longer permitted (i.e. encapsulation violations). To facilitate the detection of these encapsulation violations, a set of encapsulation violation rules are proposed to analyze the monolith:

Rule 1): if a cluster's method invokes a method belonging to a class from another cluster then it is a method invocation violation.

(Rule 2): if a cluster's method accesses an attribute belonging to a class from another cluster then it is an access violation.

(Rule 3): if a cluster's class contains a reference targeting a class from another cluster then it is an instance violation.

(Rule 4): if a cluster's class inherits a class belonging to another cluster then it is an inheritance violation.

(Rule 5): if a cluster's method throws, catches or declares an exception defined in another cluster then it is a thrown exception violation.

Algorithm 1: Microservice Encapsulation Violation Detection Algorithm.

Input : clusters (sets of classes)

Result: violations (a set of class couples) These rules are applied on the AST representation of the OO source code. Using the target architecture description, the AST nodes that represent the classes in the OO source code are partitioned into clusters. Finally, the detection algorithm is applied on the clusters that are being encapsulated.

1 violations ← { }; 2 foreach ( cluster ∈ clusters ) { 3 foreach ( class ∈ cluster ) { 4 foreach ( dependency ∈ class ) { 5 if ((dependency → target) / ∈ cluster) then
Algorithm 1 presents the procedure for detecting the encapsulation violations in each cluster. For each cluster, it traverses each individual class and checks field accesses, method invocations, and type references. Each broken rule is represented as a typed violation based on the rule that was broken and is attributed to the cluster that is the source of the violation. Once each recovered cluster has been analyzed, the encapsulations violations can be healed.

HEALING ENCAPSULATION VIOLATIONS

To achieve the encapsulation of these microservices, the violations identified in the previous steps must be healed through the application of transformation rules. These transformation must either completely heal a violation or reduce it to another solvable type.

We propose a set of transformation rules to heal the encapsulation violations identified in the first step.

As mentioned previously, the encapsulation violations are as follows (1) attribute access, (2) method invocation, (3) instance creation, (4) and inheritance.

We conclude by providing an order for resolving each type of violation to avoid creating more violations during the refactoring process.

Attribute Access

The direct attribute access violation involves direct access of attributes between classes of different microservices. It can be eliminated by applying the getter/setter pattern, which involves (1) limiting the access to the attributes to within its own class, (2) adding a method for returning the value of the attribute and a method for modifying the value of the attribute, and (3) refactoring the business logic to replace direct read/write of the attributes with method invocations to the get/set methods. This refactoring eliminates the direct access of attributes between classes of different microservices but creates a method invocation violation in its stead.

Method Invocation

The first encapsulation violation covered is the one caused by method invocation. To remove method calls between classes belonging to different microservices, they are refactored into interface-based calls. Nevertheless, ContentProvider remains inaccessible to DisplayManager via the required interface. As microservice can only interact through inter-process communication protocols, an additional technological layer must be added. In the microservice with the provided interface, a WebService class is created to implement the interface and to expose the methods of ContentProvider to other microservices. For each publicly-available method of ContentProvider, a method is created in the WebService that acts as the intermediary to receive a request, forward it to the real method, and return the result of the operation. In the microservice with the required interface, a We-bConsumer class is generated which implements the interface by preparing the network calls to its corresponding WebService class.

Instance Creation and Handling

After fragmenting the monolithic code into different microservices (i.e. clusters of classes), some instances can be created in one microservice and used (i.e. referenced) in others. To remove this type of violation, it is necessary to provide adequate answers to the following two questions: (1) How do we create an instance of a class belonging to another microservice? (2) When a given instance is referenced in several microservices, how do we ensure the sharing of this instance while preserving the business logic of the application? These two questions are answered in two parts.

Instance Creation

To answer the first question, we propose a transformation combining two design patterns: the Factory Pattern and the Proxy Pattern. To address the instantiation of objects, we replace the instantiation of Con-tentProvider by the class DisplayManager with an interface acting as an object factory. This interface defines a method for each constructor of the Content-Provider class. For simplicity, the same provided/required interfaces defined in both microservices are used to define the object factory methods and the public methods of the ContentProvider class. The methods of this factory are implemented in the WebService class and call the corresponding constructor. The next step towards transforming the instance creation violation is based on the Proxy Pattern. The intent of the proxy pattern is to provide a surrogate or placeholder for another object to control access to it. In Figure 5, the proxy class (ContentProviderProxy) is a surrogate for the real class (ContentProvider) and acts as the surrogate for all method invocations. The role of the proxy class is to hide the absence of the class with which it is associated and which is referenced in one microservice and defined in another. Thus, it constitutes the place where calls to the class or its instances defined outside the microservice are transferred. Thus, for any class referenced in one microservice and defined in another, a proxy class is created in the microservice that references it. This class will have the same name as the real class, the same list of public methods and the same list of constructors. However, the implementations of its methods and constructors are different from the original class. Instead, the proxy class uses the WebConsumer class to interact with the real class definition.

Instance Sharing

To preserve the business logic of the application, we propose a strategy to share an instance of a class defined in one microservice between several microservices. Furthermore, the proxy class handles the instances of this class. To differentiate, between the proxy class and the real class, the instances of the proxy class are called proxy instances, and instances of the real class are called concrete instances. A proxy instance has no state and they only reference their concrete instance. Each concrete instance is referenced by its proxy instances via the same unique reference, and any operation on a proxy instance is transferred to its concrete instance. Finally, all exchanges of the concrete instance (e.g. as a parameter, in or out) between the microservices are transformed into an exchange of the unique reference of the concrete instance. We implement the strategy as follows: A class is implemented to store all instances created in a microservice. When an concrete instance is created in a microservice through one of its factories, it sends the object to the corresponding storage class (in Fig 5, the Database class) to preserve it and this storage class returns a token for accessing the object. The microservice returns the token via its web service to the proxy instance, which stores it. Afterward, whenever the proxy instance receives a request, it transfers the request along with the token to the appropriate web service. The token provides the context whenever the web service is consumed, and the web service loads the concrete instance and invokes the corresponding method for that instance.

Furthermore, complex objects may be passed as a parameter between microservices. As microservicetype communication limited to passing simple data types such as strings and integers, we need to transform this type of exchange between microservices to be able to preserve the consistency of the application's business logic. A microservice may send or receive an object of class not belonging to it, and a microservice may send or receive an object of class that belongs to it.

For each situation, a token is passed between the microservices, but depending on the scenario the token is handled differently.

1. When a microservice receives an object of a class that does not belong to it, the microservice creates the relevant proxy and stores the token within it.

2. When a microservice receives an object of a class that belongs to it, the microservice uses the token to fetch it from its storage class.

3. When a microservice sends an object of a class that belongs to it, it must store the object and send the token.

4. When a microservice sends an object of a class that does not belong to it, the microservice must extract the token from its proxy and send it.

This approach enables the passing of complex objects between microservices, while the owner of the class handles the instances for other microservices. When a microservice receives a token, it is able to access the relevant object via the proxy class.

Inheritance Relationship

The inheritance violation is caused when a class that inherits from another class belonging to a different microservice are encapsulated. To heal this encapsulation violation, we propose a two-step transformation process inspired from [START_REF] Alshara | Migrating large object-oriented applications into componentbased ones: instantiation and inheritance transformation[END_REF]: (i) Uncoupling the child/parent inheritance with a double proxy pattern. (ii) Recreating subtyping via interface inheritance.

The inheritance link between two classes belonging to two different microservices contains several mechanisms that must be reproduced during the transformation process. The first mechanism is the extension of the definition of the parent by the child. A child class has access to the parent's attributes and methods. Furthermore, it may override the parent's methods. Finally, both child and parent method definitions may access each other's methods through the use of reference variables to the parent object or itself. The second mechanism that must be reproduced is the concept of polymorphic assignment. To preserve the first mechanism, we propose a double proxy pattern inspired by the work presented in [START_REF] Alshara | Migrating large object-oriented applications into componentbased ones: instantiation and inheritance transformation[END_REF]. In [START_REF] Alshara | Migrating large object-oriented applications into componentbased ones: instantiation and inheritance transformation[END_REF], the authors propose a double delegate pattern to preserve the inheritance between the child and its parent class, residing each in a different components.

With this approach, when a child object is created, a parent object is also created as an attribute within the child object. The child class is refactored to forward invocations of any of its parent methods (e.g. using 'super' in JAVA) to its parent object attribute, which acts as a delegate. Furthermore, the child object is also stored in the parent object and acts as a delegate to preserve the dynamic calling of overridden methods (i.e. 'this' in JAVA). This effectively reduces the inheritance encapsulation violation into an instantiation violation and a method invocation violation which can be healed at a later point. When the parent class is abstract, the authors apply a proxy pattern in which the proxy class inherits from the parent class. The child class can then instantiate the proxy class as its delegate.

When this approach is applied in the context of microservices it necessitates two proxy classes as the delegate pattern creates an instance violation when the child accesses the parent object and vice versa. This is valid whether the parent is an abstract class or not. However, this approach requires refactoring the internal code of the child (and parent) class and requires informing the developer to use the delegate pattern instead of the native implementation. Instead, we propose a revised version that treats inheritance as a service more than an object, and reduces the refactoring of business classes.

Decoupling the Child/Parent Inheritance

To transform the inheritance violation, the inheritance link between the child and parent classes must first be decoupled. First, a proxy class (e.g. ContentConsumer) is created and implements the methods defined by the common interface (IContent) extracted from the parent class. This class will act as the parent delegate for the the child class. The child class is refactored to extend it (e.g ContentConsumer) instead of the parent class. Then, another proxy class (e.g. MessageConsumer) is defined to extend the parent class, and acts as the child delegate for the parent class. Figure 6 illustrates the severance of the inheritance link between the child (Message) and the parent classe (e.g. Content). However, the business logic between Message and Content is not preserved.

Recreating Subtyping through Proxy Inheritance

To preserve the internal logic between the child and the parent classes, the proxy classes are exposed as web services (as seen in section 5.3). This results in the creation of two web services (Figure 6). The parent proxy (e.g ContentConsumer) consumes the Parent web service upon creation. This has the effect of creating an IContent instance that acts as the superclass delegate. Whenever a method defined by the parent class is invoked by the child object, the parent object will be invoked via the parent web service. Furthermore, when the parent class references the instance, it will invoke the child object through the child proxy (e.g MessageConsumer) object.

Recreating Polymorphic Assignment through Interface Inheritance

Finally, the polymorphic mechanism is recreated by defining a child interface (e.g IMessage) which extends the parent interface (e.g. IContent), and which will be implemented by the child class (see Figure 6).

Healing Violation Order

Once all the different microservice encapsulation violations have been identified, the transformation rules can be applied to completely encapsulate the clusters into their microservices. However, the application of these transformations in the wrong order may produce more encapsulation violations as a result (e.g. the application of the transformation for an attribute access violation produces a method invocation violation). The goal of this subsection is to present an order for applying these transformations to solve all encapsulation violation in one iteration. Therefore, we propose an order of transformation to heal all these encapsulation violations which is presented in Figure 7. First, the attribute access violation is reduced as it adds public methods to its class that may be further refactored by inheritance violation. Then, the inheritance violations are reduced to an instance violation so all instance violations can be healed together. These instance violations are reduced to method invocation violations. Finally, the remaining method invocations violations are transformed into a set of web services. In the next section, we apply this transformation order when healing the encapsulation violations identified in the selected applications.

EVALUATION 6.1 Data Collection

To establish our experiment, we select a set of monolithic applications of various sizes (small, medium and large). We identified 6 applications whose source code is object-oriented and publicly available. The seventh application, Omaje, is a closed-source legacy application by Berger-Levrault, an international software editor. Table 1 provides some metrics on these applications.

Data Pre-processing: Microservice Identification

We used our approach, proposed in [START_REF] Selmadji | From monolithic architecture style to microservice one based on a semi-automatic approach[END_REF] to recovery an MSA represented as clusters of classes. This MS architecture recovery approach is semi-automatic as it combines the information extracted from the source code of the application (e.g. coupling and cohesion between classes, coupling compared to persistent data, etc.) as well as the architect's recommendations (e.g. granularity of microservices, their number, etc.). These clusters along with the source code of the applications are used as input for our approach. Table 2, refers to the extracted architectures for each application.

Research Questions and Their Methodologies

To validate our approach, we conduct an experiment with the goal of answering the four following research questions.

RQ1: What is the Precision & Recall of MonoToMicro Approach When

Materializing a MSA?

Goal: The goal of this research question is to evaluate the correctness of the resulting microservice-based applications. By evaluating the syntactic and semantic correctness, we aim to demonstrate that our approach is able to transform the source code of a monolithic application towards an MSA one, while preserving the business logic.

Method: We measure the precision and the recall of our approach based on the syntactic and semantic correctness of the transformed microservices. It stands to reason that if the resulting MSA applications behaves in the same way as the monolithic applications then the business logic was preserved.

We consider that microservices are syntactically correct if there are no compilation errors. To measure the semantic correctness, we rely on whether the transformed microservices produce the same results compared to the functionalities of the monolithic applications at runtime. We identify a set of execution scenarios that are applied to both versions. We compare the outputs of the monolithic application with its MSA counterpart for each execution scenario. We consider that the transformation is semantically correct when the outputs generated by the monolith and the MSA are identical based on the same inputs.

When possible, the identification of execution scenarios is based on test cases defined by the developers of the monolithic applications (e.g. JPetStore). When test cases are not available, we identify a set of features and sub-features for each monolithic application (e.g. FindSportmates, IMS). From these features, we establish a set of user scenarios that cover all features of each application. These user scenarios are performed on the monolithic application and the results are saved. Then, these user scenarios are performed on the MSA, and the results are compared with those of the monolithic application. When they are identical we consider this as a passed test. Otherwise, they are marked as a failed test.

The precision is calculated by taking the number of tests passed by both architectures and dividing by the number of the tests passed by the MSA. While we calculate the recall by taking the number of tests passed by both architectures and dividing it by the number of tests passed by the monolith.

Due to time constraints related to the application packaging that is highly dependent on the technology of the monolith working with Spring, we study this research question with the FindSportMates, JPetStore, and InventoryManagementSystem applications. For JPetStore, we ran the Selenium tests provided with the monolithic application. For FindSportmates and Inventory Management System, we manually ran these user scenarios. Goal: The overall goal of our approach is to migrate while preserving the semantic behavior of an application. Moreover, an important aspect of the migration is that it must preserve the semantic without degrading drastically the runtime performance of the application. Therefore the primary goal of this RQ is to evaluate whether the performance impacts resulting from the migration of the monolithic application to microservices are negligible when compared to the original application.

Method: To answer RQ2, we rely on the execution time of user requests. The execution time measures the delay between the time when the request is sent and the time when the response is received by the user. We compare the execution time of both the monolith and the MSA. We establish a user scenario using Omaje to compare the performance of the monolithic application with its microservice counterpart. We chose Omaje for this evaluation because its business logic is the most complex of all 7 applications.

To evaluate the performance, we simulate an increasing number of users connecting to both the MSA and the monolith, using JMeter 7 to simulate user load. As the number of user increases, we increase the number of instances of the microservice for both the monolith and the MSA. For the monolith, this involves duplicating the application. For the MSA, this involves duplicating the microservices involved in the current scenario. We consider that the refactoring results improve or maintain the quality and performance of the original code if the execution time difference between both architectures is negligible for the average user while the resource utilization is optimized. For our test we use a computer with an i7-6500U @ 2.5GHz and 16GB of ram. Table 4 shows the results of RQ1. The results show that our approach has a 100% precision for FindSport-Mates, JPetStore and InventoryManagementSystem in terms of syntactic and semantic correctness. Therefore, our approach is able to preserve the business logic with a high precision. Furthermore, the results show that our approach has a 100% recall for Find-SportMates, JPetStore and InventoryManagementSystem. The proposed transformation did not create a side-effect that was detected by failed functional tests that otherwise passed for the monolith. Therefore, our approach is able to preserve the business logic with a high recall. However, it should be noted that for JPetStore the Selenide test "testOrder" failed for both the monolithic version and the MSA version, as both checked the pricing notation using a period as a decimal separator while the testing was performed on a computer which defaults to using a comma instead. Figure 8 illustrates the number of users per scenario with the different architecture configurations. We can see, there is a small but negligible gain in performance upon the introduction of scaling for the MSA. The proposed transformations from MonoToMicro does not negatively affect the performance of the application. Our expectations were that by introducing additional network calls the performance of the migrated application would be affected negatively. However, in this scenario it was not the case. This was likely due to the parallelization aspect of scaling the requested service. By adapting the number of instances of microservices, the MSA was able to handle the increased requests and compensate for the additional network layer. In fact, as the number of parallel requests increased, the MSA performed better (on average) compared to its monolith counterpart.

Threats to Validity

Internal Validity: First, we use static analysis techniques to analyze and detect microservice encapsulation violations in the source code of monolithic applications. This type of analysis may have two types of impact. The first one is that static analysis does not take into account polymorphism and dynamic binding when handling the instance violation. However, we deal this by preparing the worst case scenario where an instance dependency is created for every sub-type. The second impact is that the static analysis does not differentiate between the used and unused source code which may result in creating more services than required. The use of dynamic analysis could reduce both impacts. But it requires instrumenting and a considerable amount of tests. We consider our approach to be adequate for source code that is not based on frameworks (e.g. Spring for java). In this sense, we do not consider, for example, the injection of dependencies on-the-fly which is one of the properties of this type of framework. This type of dependency is not identified in our approach. Also, our approach does not consider dependencies and transformations linked to the reflexivity of programming languages. Thus, in our experiment, we identified and manually resolved this type of encapsulation violation.

External Validity: First, we consider that the use of a specific architecture recovery approach [START_REF] Selmadji | From monolithic architecture style to microservice one based on a semi-automatic approach[END_REF] to have an impact on the results of the transformation phase we highlight in the paper. We consider that the types of dependencies identified and their number strongly depend on the results of the architecture extraction phase used, and the use of another extraction method would impact the results of the proposed transformation process. However, the primary goal of this experiment is not to analyze the impact of the produced architecture, but the feasibility of migrating while preserving the intended behavior of the application. Second, the proposed approach is evaluated on monolithic applications that are implemented in Java. However, the obtained results can be generalized for any OO language. We argue for this generalization because all OO languages (e.g. C++, C#) are structured in terms of classes and their relationships are realized through the same mechanisms (e.g. method calls, field access, inheritance, etc.).

RELATED WORK

Microservice-based Architecture Recovery: Recently, many works have been done on the process of extracting a MSA from an OO software, and several systematic reviews have been published on the subject [START_REF] Abdellatif | A taxonomy of service identification approaches for legacy software systems modernization[END_REF] [START_REF] Fritzsch | From monolith to microservices: A classification of refactoring approaches[END_REF]) [START_REF] Francesco | Research on architecting microservices: Trends, focus, and potential for industrial adoption[END_REF]. These works can be categorized by the input and the process used to extract the architecture. Works such as [START_REF] Baresi | Microservices identification through interface analysis[END_REF] use OpenAPI documentation of an application to extract its services. Similarly, an approach is proposed that leverages the documentation for component recovery [START_REF] Chardigny | Software architecture recovery process based on object-oriented source code and documentation[END_REF]) [START_REF] Chardigny | Search-based extraction of component-based architecture from object-oriented systems[END_REF]. While [START_REF] Selmadji | From monolithic architecture style to microservice one based on a semi-automatic approach[END_REF] use both source code and expert recommendations as input for a clustering algorithm. [START_REF] Jin | Functionality-oriented microservice extraction based on execution trace clustering[END_REF] uses both source code analysis and dynamic behavior analysis to aid during clustering process. More broadly, component recovery proposes solutions to a similar problem. In [START_REF] Kebir | Comparing and combining genetic and clustering algorithms for software component identification from object-oriented code[END_REF], genetic algorithms are used to recover components from an OO software. While in [START_REF] El Hamdouni | Component-based architecture recovery from object oriented systems via relational concept analysis[END_REF], relational concept analysis is used to extract a component-based architecture. Finally, [START_REF] Shatnawi | Identifying software components from object-oriented apis based on dynamic analysis[END_REF] uses dynamic analysis to identify components.

Transformation Towards a MSA: The goal of refactoring is to extend the lifetime of an existing software product while preserving its functional behavior via code transformation to improve the structure of the source code. To the best of our knowledge, there does not exist any work in the transformation towards microservice that attempts to automate this process. Both an industrial survey [START_REF] Francesco | Research on architecting microservices: Trends, focus, and potential for industrial adoption[END_REF] and a systematic review [START_REF] Fritzsch | From monolith to microservices: A classification of refactoring approaches[END_REF] on the subject of microservice migration, indicate a lack of tool to support the migration towards microservices. [START_REF] Bigonha | An Approach for Extracting Modules from Monolithic Software Architectures[END_REF] proposes a technique for extracting modules from monolithic software architectures based on a series of refactoring to modularize concerns through the isolation of code fragments. However, it focuses on the separation of concerns and does not address the deployment of independent modules as microservices. Besides, several works offer insights on the manual transformation such as [START_REF] Fan | Migrating Monolithic Mobile Application to Microservice Architecture: An Experiment Report[END_REF], [START_REF] Richardson | Microservices Patterns[END_REF], and [START_REF] Amiri | Object-Aware Identification of Microservices[END_REF]. [START_REF] Fan | Migrating Monolithic Mobile Application to Microservice Architecture: An Experiment Report[END_REF] presents an experiment report where the authors share their migration process on an example. [START_REF] Amiri | Object-Aware Identification of Microservices[END_REF] propose an extraction method accompanied by a manual transformation to validate their approach.

CONCLUSION

We have proposed an approach to automate the source code transformation phase of the process of migrating an application from the monolithic style to the MSA one. We focused on proposing a systematic approach to transform an OO application from the monolithic style to an MSA one, a set of transformation patterns, and an automated process that applies our systematic transformation approach. The evaluation of our approach revealed that the systematic transformation were possible and created syntactically and semantically correct microservices. Furthermore, an initial performance evaluation on an industrial case revealed that successfully-migrated microservices were able to scale with increased demands without degrading the overall service. In future works, we plan to take the lessons learned from the refactoring of these monolithic applications towards MSA ones and apply them to the identification of microservices to optimize the performance and the structure of the MSA.

Figure 1 :

 1 Figure 1: Information Screen class diagram inspired (Alshara et al., 2016).

Figure 2 :

 2 Figure 2: Recovered Microservice Architecture for the Information Screen application.

Figure 3 :

 3 Figure 3: The Transformation Process using the MonoToMicro tool.

4

  Consider our motivating example, where the Display-Manager invokes a method from ContentProvider depicted in Listing 1. For DisplayManager that uses the ContentProvider, both a required and a provided interface (IContentProvider) are created. The required interface is defined in the microservice of the class DisplayManager and the provided interface is defined in the microservice of the class ContentProvider. The references of the ContentProvider in DisplayManager are replaced with a reference towards the required interface IContentProvider (see Listing 2String content = cp.pop().getContent(); ... cp.pop().getContent(); 15 } 16 } 17 public class ContentProvider implements IContentProvider{...}Listing 2: Decoupling method invocation by creating an interface.

Figure 4 :

 4 Figure 4: Replacing the class instantiation with the Factory Pattern (in yellow the monolith's class, and in green the classes created during the transformation).

Figure 5 :

 5 Figure 5: Replacing access to an object with the Proxy Pattern.

Figure 6 :

 6 Figure 6: Polymorphic assignment can be recreated by applying an interface inheritance between the Parent Interface and the Child Interface.

Figure 7 :

 7 Figure 7: The transformation order of each microservice encapsulation violation.

  7 https://jmeter.apache.org/

Figure 8 :

 8 Figure 8: Average execution time of Omaje based on the number of users and the corresponding architecture.

Table 1 :

 1 Applications on which the experiment was conducted.

	Application name No of classes	Lines of Code (LOC)
	FindSportMates 1	21	4.061
	JPetStore 2	24	4.319
	PetClinic 3	44	2.691
	SpringBlog 4	87	4.369
	IMS 5	94	13.423
	JForum 6	373	60.919
	Omaje	1.821	137.420

Table 2 :

 2 Data on the applications being transformed.

	Application	No. MSs	No. data classes	No. violations
	Findsportmates 3	2	9
	JPetStore	4	9	21
	PetClinic	3	7	26
	SpringBlog	4	8	104
	IMS	5	18	113
	JForum	8	37	1031

Table 3 :

 3 Type of violations caused by OO-type dependencies between microservices.

	Application	No. Instances	No. Inheri-tances	No. Exceptions
	Findsportmates 9	0	0
	JPetStore	20	0	0
	PetClinic	24	2	0
	SpringBlog	95	7	2
	IMS	110	3	0
	JForum	1013	16	2
	6.3.2 RQ2: What are the Impacts of
	MonoToMicro on the Performance?

Table 4 :

 4 Number of tests performed based on the application and the resulting precision and recall based on those tests.

	Application	No. Test Precision Recall
	Findsportmates 7	100%	100%
	JPetStore	34	100%	100%
	IMS	36	100%	100%

6.4.2 RQ2: What are the Impacts of

MonoToMicro on the Performance?

Refactoring Monolithic Object-Oriented Source Code to Materialize Microservice-oriented Architecture

https://github.com/chihweil5/FindSportMates

https://github.com/mybatis/jpetstore-6

https://github.com/spring-petclinic/spring-frameworkpetclinic

4 https://github.com/Raysmond/

SpringBlog 5 https://github.com/gtiwari333/java-inventorymanagement-system-swing-

hibernate-nepal 6 https://github.com/rafaelsteil/jforum2/ Refactoring Monolithic Object-Oriented Source Code to Materialize Microservice-oriented Architecture


domain: shs info

text:
When predictive modelling meet participatory simulation: a feedback on potential and issues of a combined approach Nicolas BRAX * , Frédéric AMBLARD * , Nicolas BECU ** , Laure SANTONI *** , Samuel THIRIOT *

Introduction

In the domain of agent-based simulation two main uses of simulation as a decision support system are classically identified and differentiated. The first, let's call it the "classical" simulation, involves the decision maker as a user of a model, which is viewed as an oracle that enables him to test the implications of different management scenarios. In the second viewpoint, participatory modelling and simulation involves several users, the simulation taking the place of an artefact needed for the interactions among users to take place, the overall experimentation having broadly three different possible purposes, i.e. either educational, the aim of the simulation is then to make participants learn about important aspect of the modelled system; or either experimental, the researcher aims at eliciting, through their participation to a simulation game, the strategy and decision rules of the participants; or finally operational, i.e. the simulation is an artefact that aims at helping participants to coordinate their strategy towards a collective management, for instance of natural resources. Notice that this latter case is in fact quite close to the "classical" use of simulation, a community of participants using the simulation as an oracle to test different collective management scenarios.

Participatory simulations require plausible models for making it as immersive as possible (Colella 2000, Guyot andHoniden 2006); yet predictive models built for decision-making are precisely designed for being realistic. Reciprocally, building a decision-support model requires the description of plausible behaviour for agents, while participatory simulation precisely offers the actors to play their own role with as much realism as possible. In this paper, we propose to change what looks like an interdependence dilemma to a complementary approach that uses the strength of each approach to fulfil the needs of the other: we propose to use a participative process to gather information on behaviours and decision rules of the local actors, and reciprocally to use the more realistic model built that way to improve the decisionsupport model.

Several problematic are inherent to the coupling of these two approaches. First, agents on the classical model should be made "un-pluggable" for them to be replaced by humans. This implies the design of the relevant user interfaces to enable players to act as agents. Secondly, human players are much less numerous than the artificial ones; as a consequence, their actions may have so few impact of the simulation that they would not benefit from the role-playing game. Experimentations are mandatory to assess the potential of such an approach; for instance, the re-usability of players' behaviour is unsure. One could also fear biases in such a coupling, such as having players that would play against the computer rather than with it.

In this article, we first describe an experiment based on a simulation model developed on the NetLogo platform in a water management case study and the use of this model in a participatory setting. We will then detail the solutions we found to solve the various problems inherent to such a coupling, and point out the various pitfalls and pratfalls of such a coupling, along with the potential benefits for both participatory simulation and classical modelling. 2 Study about water management in period of scarcity.

Decision support simulation: the SIMPAGE project

One aim of the study was to set up a decision-support model to study water management in the Adour-Garonne basin, especially during the low water period. The basin is positioned in the south west of France. It corresponds roughly to a 1/5th of the French metropolitan territory. It includes 120.000 km of rivers and 634.000ha of irrigated fields. Water scarcity is frequent in this basin with an annual deficit in water estimated to 300 millions of m3. In period of scarcity, the needs of the various water users (farmers, industries, hydroelectric producers and potable water managers) become conflictual, the individual and collective objectives being eventually contradictory [START_REF] Ostrom | Rules, Games, and Common-Pool Resources[END_REF]. In order to solve these conflicts, an institutional framework was set up in which the higher authority -the prefectmay punctually limit the water consumption of several actors or request dam managers to release water into the river.

As the model was intended to be used for decision-support, it was important that the interfaces could be well understood by the different users. When building this descriptive model, we choose to put much efforts on the spatial representation of the Adour-Garonne basin in the model. For this, we assumed that a cartographic GIS-like representation of the model's environment was likely to allow a consistent analysis of the simulation results by the end-users. The first step was thus to integrate in the model the shape and river network of the watershed and major geographic points (townships, water uptake points,...).

The second step was to add the agents in the environment. There are five kinds of agents, based on the different actors identified in the watershed [START_REF] Saqalli | Investigating Social Conflicts Linked to Water Resources through Agent-Based Modelling[END_REF]): farmers watering their fields, industries using water in manufacturing process, dam managers handling the water flow for electricity production, drinking water managers pumping water for citizens needs, and the water prefect (single character and agent) regulating water consumption and representative of the authorities. Again, using GIS data enabled to position agents of the different kinds in the environment. Finally, the GIS data indicate rivers locations and we use them to draw the rivers in our environment and put water agent on the notable locations of the water network (uphill, downhill, junction, capture point) and then link the agents to rebuilt the network and generate water movement in the environment.

Finally, in addition to the attributes, sensors and abilities, we added functions to the agents giving them several behaviours based on the consumat approach (Janssen and Jagger 2001).

In brief, agents are able to choose to uptake water or not according to the resource level and their production need. This model was studied by experts in water management, acknowledging it is model realistic enough to run different scenarios and produce consistent results for analysis of the various water needs and impacts of actors decisions on the water management system.

A Role-playing game experiment to better understand actors' strategies

Implementing a role-playing game (RPG) on the basis of an already existing agent-based model requires two main tasks. First , to transpose the automatic actions done by agents of the model into a set of options and rules for a person to play a role. Second, to create an immersive situation for participants to act according to their role and the study. In this experiment we choose to develop a RPG mixing human-controlled and computer-controlled agents (also called Hybrid Agent-Based Simulation Model (Becu et al., forthcoming 2010), with the possibility to switch from one control-mode to another during the course of a simulation.

The way to immerse participants into a RPG highly depends on the context and issue studied. So to immerse participants and make them aware of water management issues at this scale, we started the RPG session with a slide-show displaying pictures of the different water uses and resource conditions (e.g. rivers in low water period). Then, in order to transpose agents' automatic actions into rules and decision options for participants we used synthetic role sheets. The role sheets provide information about the goals of the player (e.g. retain water for the hydroelectric producer role), the means to fulfil his objectives (e.g. water sources for the farmer role), as well as figures and tables summarizing technical aspects related to a role (e.g. theoretical filling curve of hydroelectric dams).

Then, participants were seated at separated desks where they received their role sheets and discovered their individual objectives. They are free to elaborate a strategy that would either try to match both individual and collective objectives or to follow a more individualistic path.

During the eight turns of the game, the players have two way to gain information about their individual decisions: public announcements about the evolution of hydrological conditions in the basin or through the GIS-like spatial interface.

Finally, to capture participants strategies, four recording methods were used. First the automatic recording of all manipulations done on the custom interface (including the comments filled-in by the participants). Second, video recording when the Prefect player calls all participants for a meeting to discuss about collective water management. Next, by having a person in charge of observing participants' attitudes and interactions during the entire session. And last by conducting a collective debriefing at the end of the game session during which participants are asked to explain the reasons of the decisions they took. This material enables conducting an ex-post in-depth analysis for better understand participants' strategies.

A mixed agent-based simulation with human and virtual agents

In order to enable users to play the role of agents in this model, we make some adjustments to the original NetLogo model. We used the NetLogo networking functions to enable each player to connect to the simulation on his own computer. When a human player joins the game, he is able to choose the role he wants to play and then, he replaces an agent on the environment, acquiring its attributes, skills and capacities. The possible roles for a player are settled according to the different actors identified in the study (farmer, dam manager, … see above). Besides, to facilitate immersion and enhanced plausibility, the graphical user interface depends on the player role during the simulation.

Human player are by far less numerous than agents; for instance, the model counts hundreds of farmers, while only two or three humans played this role during the participatory simulation. The consequence is that artificial agents are required to play the role of the hundreds of other agents, which have a plausible artificial behaviour designed by a standalone model. However, the limited representation of humans among agents also limit the impact of players' actions on the system. In other words, like in reality, a single actor does not have the power to change the whole world. But this limited power may also become an issue if human players are outnumbered by artificial agents so they can't appreciate the effects of their choices and actions. It's what we name the "dissolution problem". It is a drawback from the participatory viewpoint because the player can't see his actions' consequences. Due to this, the players would not discover positive or negative impacts of their behaviours and the pedagogical purpose of the participatory simulation would not be satisfied. We solved this problem by representing human players as leaders for a proportion of agents. These agents are dedicated to mimic players' actions and the size of this set allows to interfere on the players' power.

Feedback & discussion

The problem of the dissolution of players' action because of their weak number was solved by our proposal to give the player a role of leader whom behaviour is mimic by several artificial agents. One unique player, in charge of drink water in the RPG, complained about the lack of impact of his actions on the system; in fact this impact is also very low in the studied watershed. This may suggest at the first look that involving human players for agents having few impact on the system is useless; however, such a complain during the debriefing reunion may be of help for other players to understand the weak impact of the other player, which could be of use if this role is involved in a conflict in the real system.

We reused for the graphical interface of players the very same captors and effectors that those of artificial agents. In this experiment, no player complained about a lack of information for reaching his goals, supporting the choices made during the modelling process. Note that such a direct mapping would have failed in the model wouldn't have built for being descriptive.

The experiment also learned us that their presentation may be of importance; for instance, a player in the role of dam manager asked us to change the unit for displaying the amount of water available in the dam.

The pedagogical purpose of the participatory simulation was satisfied, as participants declared to have understood not only the difficulty of water management in the watershed, but also the necessity for each player to take others' needs into account. All the players were very implicated in the simulation, some of them being even impassioned during the RPG. The conjunction of both a descriptive model that describes the socio-environmental system in a plausible way and a well managed participatory experiment probably explains this success, confirming the interest of such a coupled approach. Also, one risk identified with this coupled approach was players to try to challenge the computer like in video games. It could result in biases in simulation results. However, we didn't observed this phenomenon in this experience because of a careful introduction to the RPG. The experiment also brought benefits to the model itself, notably as being a solution to drive a careful and deep validation of the plausibility of each component of the model. For instance, dam manager detected excessive values for the volume of water contained in their dam; even if that fact was next shown to have no impact on the simulation results, the participatory simulation detected this flaw that had passed previous validation steps, suggesting that participatory simulation may be of use to enhance the validation of models.

Given this experiment, coupling a descriptive decision-support system with a participatory simulation appears to provide benefits to both of them. The plausibility of the model is checked during the RPG, while the participatory simulation becomes more immersive to the players. The solutions we propose to actually couple these approach appear to be relevant. This approach may constitute a way to parameter agents' behaviours on scenarios that cannot be tested in a real setting, in order to complete the spaces of models' parameters that cannot be defined using field observations. Without surprise, several questions remain open; among others, appropriate methods are still required to study the behaviours gathered during the participatory simulation.

FIG. 1 -

 1 FIG. 1 -Screenshot of the GIS viewpoint of the model built for water management in scarcity period.

Acknowledgment

This work was partially supported by the Réseau Thématique de Recherche Avancée Sciences et Technologies pour l'Aéronautique et l'Espace (RTRA STAE) through project MAELIA.


Ali Ballout
email: ali.ballout@inria.fr

Célia Da Costa Pereira

Andrea G B Tettamanzi
email: andrea.tettamanzi@unice.fr

Predicting the Acceptability of Atomic Candidate OWL Class Axioms

Keywords: Ontology Learning, OWL Class Axioms, Concept Similarity, Reasoning

The task of evaluating the fitness of a candidate axiom against known facts or data is known as candidate axiom scoring. Being able to accurately score candidate axioms is a prerequisite for automatic schema or ontology induction, but can also be useful for ontology and/or knowledge graph validation. Accurate axiom scoring heuristics are often heavy to compute, which is a big problem if one wants to exploit them in iterative search methods like level-wise generate-and-test or evolutionary algorithms, where large numbers of candidate axioms need to be scored. We tackle the challenge of learning a predictive model as a surrogate to reasoning, that predicts the acceptability of candidate class axioms, that is fast to execute yet accurate enough to be used in such settings. For this purpose, we leverage a semantic similarity measure extracted from the subsumption hierarchy of an ontology. We prove that the method proposed in this paper is able to learn the acceptability labels of candidate OWL class axioms with high accuracy and that it can do so for multiple types of OWL class axioms.

I. INTRODUCTION

Ontologies play a crucial role in organizing digital information by categorizing entities and defining their relationships [START_REF] Hawthorne | Ontology, archetypes and the definition of 'mineral species[END_REF]. Despite their importance, creating and maintaining ontologies is resource-intensive, often requiring domain experts. Ontology learning aims to mitigate this by automating ontology construction and enrichment [START_REF] Ramesh | Web mining based framework for ontology learning[END_REF].

Ontology learning is a multidisciplinary field, incorporating techniques from:

• Natural Language Processing (NLP) for data preprocessing and term extraction [START_REF] Asim | A survey of ontology learning techniques and applications[END_REF]. • Data-driven methods like data mining for identifying terms and their relationships [START_REF] Fleischhacker | Inductive learning of disjointness axioms[END_REF]. • Inductive Logic Programming (ILP) to generate hypotheses based on existing knowledge [START_REF] Fanizzi | DL-FOIL concept learning in description logics[END_REF]. These techniques contribute to various stages of ontology learning, including preprocessing, term extraction, and relation identification [START_REF] Asim | A survey of ontology learning techniques and applications[END_REF]. However, they come with limitations like high computational cost and reliance on potentially inaccurate data.

Our work introduces a new approach that overcomes these limitations by reducing computational costs and improving accuracy. Specifically, our method predicts labels for a range of axiom types without relying on error-prone statistics.

The remainder of this paper is organized as follows: Section II discusses related work, Section III provides essential background, Section IV describes our methodology, and Section V presents our experiments and findings. We conclude with notes and observations. II. RELATED WORK Data-driven ontology learning methods such as the possibilistic heuristic by Tettamanzi et al. [START_REF] Tettamanzi | Possibilistic testing of OWL axioms against RDF data[END_REF] focus primarily on statistical analyses using RDF data. Although these methods achieve high accuracy, they are time-consuming and susceptible to errors. An attempt to mitigate the time issue through time-capping resulted in a slight increase in the error rate [START_REF] Tettamanzi | Dynamically timecapped possibilistic testing of SubClassOf axioms against RDF data to enrich schemas[END_REF].

Inductive Logic Programming (ILP) offers alternative approaches, exemplified by the SoftFOIL method [START_REF] Lisi | A logic-based computational method for the automated induction of fuzzy ontology axioms[END_REF]. While effective in automating the induction of fuzzy axioms, it suffers from limitations such as a greedy search algorithm and the risk of entering infinite loops.

Emerging hybrid methods aim to combine the benefits of both ILP and statistical learning. One example is the work by Malchiodi et al. [START_REF] Malchiodi | Predicting the possibilistic score of OWL axioms through modified support vector clustering[END_REF], which modified the support vector clustering algorithm to predict the possibilistic scores for OWL axioms. These methods show promise but are resourceintensive.

For OWL class axiom labeling, frameworks like that developed by Ballout et al. [START_REF] Ballout | Learning to classify logical formulas based on their semantic similarity[END_REF] employ semantic similarity for training models focused on the binary classification of axioms. These approaches have demonstrated efficacy but are not standalone solutions [START_REF] Ballout | Predicting the score of atomic candidate owl class axioms[END_REF].

In our current work, we aim for efficient and accurate binary classification of candidate axioms. Our method is designed to function either as a standalone labeler or as an extension to existing methods like DL-Learner [START_REF] Bühmann | Dl-learner-a framework for inductive learning on the semantic web[END_REF]. We benchmark our approach against state-of-the-art description logic reasoners using DBpedia to validate its efficacy and efficiency.

III. BACKGROUND

Our primary goal is to create a model for predicting the acceptability of axioms, independent of potentially error-prone instance data. This necessitates a labeled training set of axioms and a method for determining their semantic relationships as model features.

Semantic similarity serves as a measure of the semantic closeness between ontological concepts, often based on the subsumption (rdfs:subClassOf) relation [START_REF] Ballatore | An evaluative baseline for geo-semantic relatedness and similarity[END_REF]. This is distinct from semantic relatedness; for instance, a train and an airplane are semantically similar as both are vehicles [START_REF] Ballatore | An evaluative baseline for geo-semantic relatedness and similarity[END_REF], [START_REF] Corby | Searching the semantic web: Approximate query processing based on ontologies[END_REF]. Such similarity measures are often based on path lengths and node depths in a subsumption hierarchy, or on information content derived from ontology and corpus statistics [START_REF] Al-Mubaid | A cluster-based approach for semantic similarity in the biomedical domain[END_REF].

Corby et al. proposed a semantic similarity measure based on the ontological distance between concepts in an inheritance hierarchy [START_REF] Corby | Searching the semantic web: Approximate query processing based on ontologies[END_REF]. The ontological distance is calculated using the lengths of subsumption paths and the depths of concepts in the hierarchy. This measure has been implemented in the Corese software platform [START_REF] Corby | Querying the semantic web with corese search engine[END_REF], which we employ to compute concept similarity in our method.

DH (t1, t2) = mint(lH (⟨t1, t⟩) + lH (⟨t2, t⟩)) = mint {x∈<t 1 ,t>,x̸ =t 1 } 1/2 d H (x) + {x∈<t 2 ,t>,x̸ =t 2 } 1/2 d H (x) . (1)
In summary, the ontological distance D H (t 1 , t 2 ) in hierarchy H is the minimum sum of subsumption path lengths between t 1 and t 2 and a common supertype. The path length from a type t 1 to its direct supertype t is 1/2 d H (t) , where d H (t) is the depth of t in H. This measure is implemented in the Corese1 software platform [START_REF] Corby | Querying the semantic web with corese search engine[END_REF], which we use for computing concept similarity in our approach.

IV. METHOD

In an OWL ontology containing an inheritance hierarchy of concepts formed by the subsumption axiom rdfs:subClassOf, our aim is to predict if a candidate atomic axiom (consisting of a single named class on each side) is accepted or not. We do this by training a model on a set of previously labeled axioms of the same type (one of: subsumption, disjointness, equivalence) and their similarity weights. In the absence of a scored set our method creates one using explicit axioms available in the ontology. To measure the similarity between (candidate) axioms, we construct a similarity measure by extending the ontological distance discussed in Section III, which is defined among classes, not axioms. This enables the model to predict the label of any new atomic candidate axiom of the same type. To this end, we consider the following steps:

1) OWL ontology closure reasoning: This step involves using DL-Reasoners the likes of HermiT [START_REF] Glimm | HermiT: An OWL 2 reasoner[END_REF] and Pellet [START_REF] Sirin | Pellet: A practical owl-dl reasoner[END_REF] to infer all the axioms (binary relations between named classes) that can be inferred from the knowledge available in the ontology.

In this paper, we use it when testing the ability of our model to accept axioms that are not entailed by a reasoner, or to reject ones that are entailed by a reasoner. 2) Axiom extraction and labeling: This step constitutes the creation of the set of accepted and rejected labeled axioms of a certain type to be learned. One approach can be querying existing axioms and labeling them as accepted/rejected. Another is to use a scorer to label a set of generated candidate axioms to learn.

3) Semantic measure retrieval and assignment: This step involves the retrieval of concepts used in our set of axioms, and their ontological distance from the ontology, followed by extending that similarity to those axioms. This was done by calculating a single value that represents the similarity between each pair of axioms, by applying a function such as Average to the ontological distances of concepts in those axioms. 4) Axiom base vector space modeling: This step focuses on using axiom similarity measures as weights, each axiom can be represented as a vector in an axiom based vector space. 5) Binary Classification: This step is dedicated to training a Machine Learning model with the data set (vector space model in addition to the extracted labels) and predicting if new candidate axioms are accepted or rejected.

A. OWL Ontology Closure Reasoning

The optional first step in our methodology involves inferring all entailed axioms from a target OWL ontology, particularly useful when the ontology is rich in explicit axioms. This serves two purposes:

1) Enlarging the training set of axioms, enhancing the experimental accuracy and facilitating performance comparison with DL-reasoners. 2) Enabling the filtering of new labeled or scored axioms against our ontology closure, allowing us to assess the model's performance on axioms not entailed by reasoners.

B. Axiom Extraction and Labeling

In this work, we used two strategies to create a set of labeled axioms. The first approach utilizes existing scoring methods or previously scored axioms from literature. The second, a faster method, is what we term the "type and counter-type technique."

1) Scoring Method: We used multiple sets of scored axioms for the ontology DBpedia, one set2 of axioms generated and scored by Nguyen et al. [START_REF] Nguyen | An evolutionary approach to class disjointness axiom discovery[END_REF] using the possibilistic heuristic [START_REF] Tettamanzi | Possibilistic testing of OWL axioms against RDF data[END_REF]. The rest of teh sets we scored ourselves using the same heuristic. The scorer though accurate, is extremely slow limiting the size of the sets scored. The scorer currently supports DBpedia and is publicly available 3 . We utilized the version detailed in the work of Felin et al. [START_REF] Felin | Optimizing the computation of a possibilistic heuristic to test owl subclassof axioms against rdf data[END_REF]. These scored data sets are what we use for our evaluation and comparison with reasoners in the case of DBpedia. The possibilistic heuristic scores are considered our ground truth and baseline. For experiments using other ontologies we employed the second approach.

2) Type and Counter Type Technique: In this technique, we query an ontology for existing axioms of a certain type, thereby obtaining a set of axioms labeled as accepted. We then query axioms of the counter type. For instance, subClassOf and disjointWith can be considered counter types to each other. Axioms of the counter type are assigned the label rejected. Since existing disjointWith axioms can be considered false or rejected subClassOf, we can construct a sample containing both labels to train a model. We consider disjointWith to be a counter-type for subClassOf and equivalenntClass. While subClassOf and equivalenntClass are counter-types of disjointWith. However, before querying an ontology for existing axioms, it is advisable to apply a reasoner to obtain the closure of the ontology. The reasoner can be any suitable choice, such as HermiT or Pellet, and not necessarily the reasoner included in the engine used. By applying a reasoner to obtain the closure of an OWL ontology, we ensure that we obtain a complete and consistent set of labeled axioms for our model.

The axiom type designated as accepted corresponds to the type that the model will be labeling. For instance, if we assign the accepted label to disjointWith axioms, it implies that disjointWith is the axiom type that the model is designed to address. While this may initially appear as a limitation, the efficiency of the process mitigates this concern. As demonstrated in Table II, which details the time consumption, the speed of dataset preparation and model training is sufficiently rapid. This allows us to learn a model for each type of axiom within a relatively short time frame.

We employ Query 1 to extract and label existing axioms of both the type and counter-type. Following the extraction, we ensure an equal representation of both type and countertype axioms. The SPARQL endpoint utilized in this process is Corese [START_REF] Corby | Querying the semantic web with corese search engine[END_REF]. We have selected DBpedia as our test case to illustrate a real-world application. While other ontologies could be employed, DBpedia offers several advantages. It has been widely used in related work and aligns well with the scoring heuristic we employ for evaluating our candidate axioms.

C. Semantic Measure Retrieval and Assignment

To be able to assign similarity measures between axioms, we need to retrieve the ontological distances between all classes a construct the concept similarity matrix (CSM). sing Corese in which the ontological distance metric is implemented, this translates into a function added to the SPARQL query. Query 2 retrieves three columns, the first two contain the combination of all classes with the third containing the ontological distance denoted by similarity. Blank nodes are ignored.

After retrieving the table of similarities it is pivoted to construct a symmetric n×n matrix where the first column and the first row are the classes and the cells are the similarities From the CSM, we can derive the axiom similarity matrix (ASM) with labels illustrated in Matrix 1, as explained in the work of Ballout et al. [START_REF] Ballout | Predicting the score of atomic candidate owl class axioms[END_REF] which also highlights that the function used to calculate the similarity S between a pair of axioms can be either Average or Minimum.

We define then a vector-space model to represent axioms as vectors. Indeed, we represent each axiom as a vector whose elements are the kernels representing the similarity value between the considered axiom and the other axioms present in the labeled dataset T A . We have been inspired by the Kernel trick in Support Vector Machine (SVM) which is used to deal with nonlinear classification [START_REF] Murty | Kernel-based svm[END_REF].

The number of dimensions m of our vector space corresponds to the number of axioms we have in T A . Each axiom is then represented as a vector V in this m-dimensional space, and corresponds to a row in the axiom similarity Matrix 1.

The axiom similarity matrix is updated whenever an axiom is generated or a new candidate axiom is suggested.

E. Binary Classification

It is now possible to apply classification machine learning methods using our labeled dataset of axioms represented as vectors. We used a range of methods throughout our experiments, including but not limited to trees, random forests, kNN, Support vector classifier, gradient boosting, and neural networks. Trees and random forests were used to check that there was no bias during the classification. The reason for this choice is that such methods allow us to interpret our predictive model easily and visually analyse the decisions. kNN instead was used to test the effect of the similarity measure as a distance (the metric used was Manhattan, due to the large number of dimensions and the weight was distances). To avoid information leakage since the matrix is symmetric, considering the size of the matrix is m × m, all predicting models were trained using an m ′ × m ′ sub-matrix, with m ′ < m, of the axiom similarity matrix with the labels, and then tested on the (m -m ′ ) remaining axioms. Our goal is then to predict the

V. EXPERIMENTS AND RESULTS

For the following experiments, we used this configuration:

• Dual CPUs: 2 × Intel(R) Xeon(R) CPU E5-2689 0 @ 2.60GHz total of 16 cores and 32 threads. • A total of 32 GB of RAM memory @ 1600 MHz.

• Code and ontologies used available in our repository. 4

A. Dataset Preparation

As outlined in Section IV-E, our experiments spanned various classification methods, ontologies, and axiom types. For illustrative purposes, we will focus on disjointness axioms to demonstrate the absence of leakage or bias from using the subClassOf hierarchy. Our initial step involved constructing the datasets as follows:

1) Ontology Selection: We selected ontologies of varying sizes and domains for our experiments, with details summarized in Table I. The chosen ontologies include:

• NTNames5 : A small, hand-crafted ontology focusing on New Testament names. • Pizza6 : A medium-sized ontology from the University of Manchester, widely recognized in the field. • MatOnto7 : A material science ontology used by the Ontology Alignment Evaluation Initiative8 . • DBpedia9 : A large, real-world knowledge base derived from Wikipedia, selected for its complexity and size. This ontology was also used for DL-reasoner application and further experimentation.

2) Axiom Extraction and Labeling: Each ontology was loaded into Corese. Since in some of the ontologies the explicit number of axioms was not big enough for any meaningful experiment, we applied different reasoning methods to obtain the maximum number of deduced axioms. For all ontologies, we used Corese reasoner, which is a rule-based engine that can handle RDF(S) and OWL 2 RL profiles. For DBpedia specifically, we additionaly used Hermit and Pellet reasoners to compute the closure, a step which took two hours for each run using Protegé. 10 Additionally, we used the disjointness axioms generated and scored by Nguyen et al. [START_REF] Nguyen | An evolutionary approach to class disjointness axiom discovery[END_REF] for DBpedia, as explained in Section IV-B. After that, we extracted a balanced set of Accepted and Rejected axioms from each ontology using SPARQL queries and the technique of type and counter type explained in Section IV-B2. For instance, for subsumption in DBpedia, we selected 4300 Accepted and 4300 disjointWith axioms representing Rejected subClassOf axioms, resulting in a total of 8600 axioms for T A , which is our axiom dataset for this scenario.

Explicit axiom extraction by querying an ontology using a SPARQL endpoint needs minimal time, as for generating a set of labeled axioms as in [START_REF] Nguyen | An evolutionary approach to class disjointness axiom discovery[END_REF] the time cost would depend on the scorer and the method used to generate candidate axioms.

3) Concept Similarity Matrix: After preparing the set of axioms, we have to produce the concept similarity matrix (CSM), as explained in Section IV-C. The processing time for creating the CSM depends on the number of concepts. In our tested dataset, MatOnto had 847 concepts and creating its CSM took 2.84 seconds. In Table II we present the timings for the worst-case scenario, which consists of applying our method to the most dense axiom type that is subsumption for comparison reasons. Other axiom types are naturally much faster due to their lesser population.

4) Axiom Similarity Matrix and Vector Space: The next step is constructing the axiom similarity Matrix 1 (ASM), and encoding each of the axioms as vectors V in our vector space.

Table II details the time required to complete these operations, all the values presented are the mean average of five consecutive runs. As observed the time needed to complete the task of building the ASM significantly increases as the number of axioms processed increases, but we also know that it depends on the size of the CSM as well from the time needed to encode a single axiom into a vector. As the number of concept increases the CSM being searched increases in size as it has the shape n concepts × n concepts and the number of cells n 2 . We would like to note that the test scenario presented in Table II is extreme, especially the case of DBpedia, as the number of axioms needed for training a model does not need to be as large to achieve peak accuracy/results.

B. Training and Testing

Using the dataset obtained as described in the previous section, the classifiers we tested were Decision Trees (DT), Random Forests (RF), kNN, support vector classifier (SVC), Neural Networks (NN) and Gradient boosting (GB). Experiments were performed over every class axiom type, where the axiom population was enough, for every ontology in our dataset some results are shown in Figure 1. We also experimented with both Average and Minimum functions to We would also like to note that the model training times mentioned in Table II, are the average for the above mentioned methods except for the extreme case of DBpedia subsumption using gradient Boosting, where it may take up to 136 seconds to train the model on a set of 6, 000 axioms.

In order to prove that the proposed kernel-based representation of axioms is advantageous for addressing the task of predicting the acceptability of candidate axioms, we performed an additional experiment. For this experiment we used a simple naive kNN method using our axiom similarity measure directly to check the n nearest axioms to a candidate axiom and then assigning that candidate axiom the label that occurs most in the n neighbors. To make things fair, we compare the performance of this naive approach to our proposed kernel-based vectorspace representation of axioms, using kNN. perform the comparison using DBpedia's subClassOf axioms as a dataset. We used as a training set 200 axioms, and for the test set 4000 axioms; both sets are balanced in terms of labels.

Table IV presents the F1 scores of each of the methods as a function of the number n of neighbors. From the results we can see that the naive method performs best when the number of neighbors is 1, this is because the method does not learn anything and simply retrieves the closest axioms based on the similarity measure. Our proposed method on the other hand maintains performance since it uses the similarity matrix as a kernel to map the neighbors to a plane of dimensions equal to the number of axioms used in training. Our method outperforms the naive one by a significant margin every time. This corroborates the hypothesis that the proposed kernelbased vector-space representation of axioms is capable of capturing useful features of the semantics of candidate axioms, this offering a clear advantage over the simple and direct use of the axiom similarity matrix.

C. Proof of Concept

In order to prove that the proposed kernel-based representation of axioms is advantageous for addressing the task of predicting the acceptability of candidate axioms, we performed an additional experiment. For this experiment we used a simple naive kNN method using our axiom similarity measure directly to check the n nearest axioms to a candidate axiom and then assigning that candidate axiom the label that occurs most in the n neighbors. To make things fair, we compare the performance of this naive approach to our proposed kernel-based vectorspace representation of axioms, using kNN. We perform the comparison using DBpedia's subClassOf axioms as a dataset. We used as a training set 200 axioms, and for the test set 4000 axioms; both sets are balanced in terms of labels.

Table IV presents the F1 scores of each of the methods as a function of the number n of neighbors. From the results we can see that the naive method performs best when the number of neighbors is 1, this is because the method does not learn anything and simply retrieves the closest axioms based on the similarity measure. Our proposed method on the other hand maintains performance since it uses the similarity matrix as a kernel to map the neighbors to a plane of dimensions equal to the number of axioms used in training. Our method outperforms the naive one by a significant margin every time. This corroborates the hypothesis that the proposed kernelbased vector-space representation of axioms is capable of capturing useful features of the semantics of candidate axioms, this offering a clear advantage over the simple and direct use of the axiom similarity matrix.

D. Comparing With Reasoners

In this experiment, we compare the performance of our model with HermiT, Pellet, and Corese in accepting or rejecting candidate OWL class axioms. For this experiment, we prepare a dataset generated and scored by the possibilistic heuristic using DBpedia ontology which is widely used and represents our real-world scenario. The generation and scoring required seven days of processing time. The dataset contains: 811 accepted subClassOf axioms and 745 rejected ones, as well as 1276 accepted disjointWith axioms and 823 rejected ones. We split the dataset into training and test sets. The split was as follows: the subClassOf training set contains 399 accepted and 398 rejected, while the test set contains 412 accepted and 347 rejected. As for disjointWith, the training set contains 524 accepted and 596 rejected axioms, while the test set contains 752 accepted and 227 rejected.

We evaluated our model and the reasoners on test sets, employing two training scenarios for our model. In the first scenario, we trained our model using a set extracted from the closure of DBpedia, produced by the type counter type method. In the second scenario, we used a scored training set independent of the reasoners. We evaluated the reasoners by checking if they could entail the candidate axioms from DBpedia. If a candidate is entailed then it is labeled as accepted otherwise it is labeled rejected. We assessed precision, recall, and F1-score with our ground truth being the labels produced by the possibilistic scorer. The results presented in Table V. We noticed that the results of our model were worse when training it using the closure, and almost perfect when using the scored training set. Therefore, we hypothesized that the labels of the training set from the closure (reasoners product) could have wrong labels, while the labels from the scorer were more accurate. To test this hypothesis, we ran the scored training set through the reasoners to see how they would would label it. Indeed, the reasoners were entailing axioms labeled as rejected by the scorer, which appear to have a great impact on how the model labeled the test set. A sample of these axioms can be seen in Table VI.

E. Key Findings and Observations

In our experiments, various models trained on the same dataset showed similar results, consistently achieving high accuracy levels averaging between 90-95%. Key observations from our experiments are outlined below:

1) Axiom Similarity Function: Throughout our experiments, we have observed a consistent trend where most ASMs that were constructed using the Average function to obtain S gave better results than those that were built using the Minimum function. This can be observed in Table III.

The models are scored based on their performance on the test set (i.e., when classifying axiom candidates never seen before).

We note that Neural Networks were the only model to break this trend. It performed better when the Minimum function was used as seen in Table III. However, despite that, it had the worst performance out of all the models presented using both functions, even though different configurations were tested. 11 2) Classifier Of Choice: Tree-based models consistently achieved the highest scores. This fact is very evident in Table III, where the leading models when using the better similarity function Average were, in order: Gradient Boosting, Random Forest, and Tree. For this reason, and since all models score close to each other with an accuracy greater than 95%, we find Random Forests combined with the Average function for S to be the classifier of choice when creating the model. We chose Random Forest over Gradient Boost since the time for training Random Forest models is faster while giving up at most 0.1% accuracy.

3) Model Perfomance Dealing With Variables : We chose the confusion matrix metric to summarize the results while showing the support, and how the method performs with different sizes of datasets and ontologies as a whole. Figure 1 presents the performance of the method on three different ontologies with different sizes as well as different types of axioms and populations. It is very clear how well the method performs across all those variables. The figure shows results only from the test set, i.e., when the model predicts labels for candidate axioms it has never seen before. This brings us to the conclusion that the method is performing as expected with F1 score between 95% to 99%.

VI. CONCLUSION

We presented a method for accurately predicting the acceptability of various OWL class axioms, using a semantic similarity measure based on ontological distance. The method's robustness was confirmed through extensive testing across different ontologies.

Our approach achieved high accuracy for all OWL axiom types, making it suitable for integration with existing methods like DL-Learner [START_REF] Bühmann | Dl-learner-a framework for inductive learning on the semantic web[END_REF] or Grammatical evolution approaches [START_REF] Nguyen | Learning class disjointness axioms using grammatical evolution[END_REF]. The effectiveness is attributed to the semantic similarity measure's ability to capture the axioms' modeltheoretic semantics, suggesting avenues for further research into the relationship between similarity measures and axiom truthfulness.

Future research directions include:

0

  SELECT ?class1 ?class2 ?label WHERE { 1 { ?class1 a owl:Class . ?class2 a owl:Class . ?class1 rdfs:subClassOf ?class2 2 filter (!isBlank(?class1) && !isBlank(?class2)) 3 filter (?class1 != ?class2) 4 bind(1.0 as ?label) } 5 Union{ ?class1 a owl:Class . ?class2 a owl:Class . ?class1 owl:disjointWith ?class2 6 filter (!isBlank(?class1) && !isBlank(?class2)) 7 filter (?class1 != ?class2) 8 bind(0.0 as ?label) }} Query 1: Axiom extraction

Figure 1 :

 1 Figure 1: Performance by axiom type for investigated ontologies

TABLE I :

 I Ontology statistics. Reasoner used: Corese built in reasoner: C , Pellet: P , Hermit: H .

	Ontology	Classes subClassOf disjointWith equivalentClass
	NTNames C	47	278	10	50
	Pizza C	101	651	5	101
	MatOnto C	847	853	158	9
	DBpedia H P C	866	7334	70669	268

TABLE II :

 II Time cost per step for investigated ontology in seconds for subClassOf. The labels are binary, where 1 represents the label Accepted and 0 represents the label Rejected.

	Ontology	CSM	Axioms	ASM	Single Axiom	Model
			processed		vector encoding training
	NTNames	0.02	556	22	0.03	0.2
	Pizza	0.04	1302	105	0.05	0.4
	MatOnto	2.84	1706	212	0.09	0.6
	DBpedia	2.17	8600	2497	0.08	3.9
	label of those axioms which have not been used during the
	training period.

TABLE III :

 III F1 scores using DBpedia owl:disjointWith, average and minimum as similarity functions. The results of such experimentation can be found in TableIIIwhere models were trained using 813 axioms split into 406 Rejected and 407 Accepted axioms, and tested on 349 axioms split into 175 Rejected and 174 Accepted.

	Function	GB	kNN	NN	RF	SVC	DT
	F1 (AVG)	0.988	0.976 0.953 0.985 0.976 0.982
	F1 (MIN)	0.977	0.974 0.962 0.976 0.962 0.968
	get the similarity between axioms S.

TABLE IV :

 IV F1 scores for the naive nearest neighbor method and our proposed method using K-nearest neighbor as the machine learning model, as a function of number n of neighbors.

	Model	n 1	n 3	n 15
	Naive	0.59 0.49 0.33
	kNN	0.86 0.87 0.86

TABLE V :

 V Performance of our proposed model when trained using a scored training set and a training set extracted from the closure of DBpedia as a product of HermiT, Pellet and Corese, compared to reasoners in accepting or rejecting axioms of different types.

			Model scored training set	Model closure training set		Reasoners
	Axiom type	Label	Precision Recall	F1	Precision Recall	F1	Precision Recall	F1
	subClassOf	Accepted Rejected	1.00 0.90	0.91 1.00	0.95 0.95	0.66 1.00	1.00 0.48	0.79 0.65	1.00 1.00	1.00 1.00	1.00 1.00
	disjointWith	Accepted Rejected	0.97 0.83	0.94 0.92	0.96 0.87	0.27 0.99	0.99 0.20	0.43 0.34	0.00 0.23	0.00 1.00	0.00 0.37

TABLE VI :

 VI subClassOf axioms rejected by the scorer and entailed

	by the reasoners
	SubClassOf(Tax Genre)
	SubClassOf(Organ Aircraft)
	SubClassOf(Guitar Locomotive)
	SubClassOf(Treadmill ArchitecturalStructure)
	SubClassOf(Quote Work)
	SubClassOf(Instrument MilitaryVehicle)
	SubClassOf(Guitar Aircraft)

https://project.inria.fr/corese/

https://bitbucket.org/RDFMiner/classdisjointnessaxioms/src/ master/Results/ClassDisjointnessAxioms/

https://github.com/RemiFELIN/RDFMining

https://github.com/ali-ballout/axiom-acceptability

https://semanticbible.com/index.html

https://protege.stanford.edu/ontologies/pizza/

https://github.com/inovexcorp/MatOnto-Ontologies

http://oaei.ontologymatching.org/

http://downloads.dbpedia.org/

https://protege.stanford.edu/

• Extending the method to complex and property axioms.• Exploring ensemble approaches incorporating active learning.11 Can be found in keratest.py in the repository