A Prototype Implementation for Decentralized Reasoning

Our implementation is a customized version of the OWL API so as to support distributed reasoning tasks. It is based on the traditional client-server paradigm, and makes it possible for a semantic web application to connect to a remote reasoning server over TCP/IP, acting as a middleware.

• It includes the following components:
  • A client application.
  • A server application.
  • Some customized files, altered variants of the original OWL API's ones.
• It requires a functional OWL API installation.

• It is open source and available under the LGPL License.

Client Application

Client application consists of two files: myReasoner.java and FunctionsDefineIndex.java.

myReasoner.java contains myReasoner class, which has two constructors. The first constructor has three arguments: an OWLOntologyManager object (OWLOntologyManager manager), a String object that defines the server's IP address (String address), and an int variable for the port that the server listens to (int port).

FunctionsDefineIndex.java has two arguments (OWLOntologyManager manager, String address) and uses the default value for the port (13000).

Thus, an original OWL API application just needs to import myReasoner.java and create a myReasoner object:

myReasoner reasoner = new myReasoner(manager, address, port);

From now on any method can be used like in the original OWL-API (i.e. reasoner.<method_name>), for example:

reasoner.classify();

FunctionDefineIndex.java contains FunctionDefineIndex interface, that defines a unique identifier (int) for each method, in order to standardize client-server communication.

Server Application

Server application consists of three files: SingleThreadedServer.java, SingleThreadedServerMain.java and FunctionDefineIndex.java.

SingleThreadedServerMain.java contains the main functions of the server application.

SingleThreadedServer.java contains SingleThreadedServer class, which has two constructors. The first constructor has one argument (int port), the port that the server listens to. The second one (default constructor) has no arguments, and uses the default value for the port (13000).

In the multi-threaded version of the server application, there is one more file, WorkerRunnable.java, in order to support multiple threads.

Additional Files

In our implementation, we tried not to make any severe changes in the original OWL API code, but it wasn't an easy task.

One problem was that, for object serialization to be used, we had to support Java Serialization Protocol. In order to avoid adding implements Serializable to all OWL API's classes and interfaces, we preferred to add extends Serializable to the definition of OWLObject interface, which is being inherited by almost all OWL API's classes and interfaces, except for some inner classes of OWLOntologyImpl class. These classes implement the interfaces: OWLOntologyChangeVisitor, OWLEntityVisitor and OWLAxiomVisitor. Thus, we added extends Serializable to all the three of them.

A second problem was that Java Serialization protocol can't byte-transform any static class variables, as found in AxiomType.java and OWLOntologyImpl.java files. In these files we had to change a bit the original OWL API's source code.

So, in order for our application to function, one has to overwrite the original OWLObject.java, AxiomType.java, OWLOntologyChangeVisitor.java, OWLEntityVisitor.java and OWLAxiomVisitor.java files (in OWL API's org.semanticweb.owl.model package), as well as OWLOntologyImpl.java file (in OWL API's uk.ac.manchester.cs.owl package) with our custom ones.

Download and Instructions

The source code of our implementation is available through the following links, as per implementation part: Client implementation, Server implementation and custom files. An application also needs to import the corresponding libraries of the original OWL API (currently, v. 2 is supported), which is available for download through SourceForge.