Drago's Home Distributed Reasoning Architecture for Galaxy of Ontologies
 
ITC-IRST
DIT
System Description

Vision

As depicted in Figure 1, DRAGO envisages a web of ontologies being distributed amongst a peer-to-peer network of DRAGO Reasoning Peers (hereafter, DRP). The role of a DRP is to provide reasoning services for ontologies registered to it, as well as to request reasoning services of other semantically related peers. The key difference of DRP from standard ontology reasoners (non distributed) is that it registers not just a stand alone ontology, but an ontology coupled with a set of semantic mappings. The reasoning services provided by a DRAGO peer can be subdivided into two groups: (1) local, when semantic mappings are ignored, and (2) distributed, when behind a local ontology the semantically related ontologies are considered.

Figure 1:

In order to register an ontology to a DRP, the users specify a logical identifier for it, a Unified Resource Identificator (URI), and give a physical location of ontology on the Web, a Unified Resource Locator (URL). Besides that, it is possible to assign to an ontology a set of semantic mappings, providing in the same manner their location on the web. Attachment of mappings to ontology enriches it knowledge due to the subsumption propagation mechanism (follow "Publications" link in the left menu to find explanatory articles). To prevent the possibility of attaching malicious mappings that can obstruct or falsify reasoning services, only the user that registered the ontology to a peer is allowed to add mappings to it.

When users or applications want to perform reasoning with a one of registered ontologies, they refer to the corresponding DRP and invoke its reasoning services giving the URI of the desired ontology.

Jump to top

Architecture

A DRP constitutes the basic element of DRAGO. The major components of a DRP are depicted in Figure 2.

Figure 2:

A DRP has two interfaces which can be invoked by users or applications:

  • A Registration Service interface is meant for creating/modifying/deleting of registrations of ontologies and mappings assigned to them.
  • A Reasoning Services interface enables the calls of reasoning services for registered ontologies. Among the reasoning services can be a possibility to check ontology consistency, build classification, verify concepts satisfiability and check entailment.

All accessibility information about registered ontologies and mappings is stored by a DRP in its local Registration Storage.

In order to register an ontology with a collection of semantic mappings attached to it (both available on the web) a user or application invokes the Registration Service of a DRP and sends to it the following registration information:

  • URI to which the ontology will be bound.
  • URLs of ontology and semantic mappings attached to it, if any.
  • If the semantic mappings connect this ontology with ontologies registered to external DRPs then additionally the URLs of these DRPs should be specified. This requirement is explained by the necessity to know who is responsible for reasoning with these ontologies.
The Registration Service interface is implemented by the Registration Manager. When the Manager receives a registration request, it (i) consults the Registration Storage and verifies if the URI has not occupied yet, (ii) if not it accesses ontologies and assigned mappings from their URLs, (iii) asks Parser component to process them, (iv) initializes the Distributed Reasoner with the parsed data, and (v) finally adds a new record to the Registration Storage.

The Parser component translates ontologies and mappings source files to the internal format used by the Distributed Reasoner. For doing so, the Parser consist from two sub components: the ontology parser, tailored on ontology language formats (for example, OWL), and the mapping parser, tailored on mapping formats (for example, C-OWL).

The Reasoning Manager component implements the Reasoning Services interface. When users, applications or other DRPs invoke this interface sending the URI of requested ontology, the Manager verifies with the Registration Storage whether the URI is registered to the DRP and, if yes, asks the Distributed Reasoner to execute corresponding reasoning task for that ontology.

The Distributed Reasoner represents a brain of a DRP. It realizes the distributed algorithm and reasons on ontologies with attached mappings that are registered to the DRP. The Distributed Reasoner is built on top of standard tableau reasoner whose algorithm was extended with the additional Bridge Expansion Rule in accordance with the distributed tableau algorithm. When the Bridge Expansion Rule is applied it analyses semantic mappings and possibly generates reasoning sub tasks that are required to be executed in the ontologies participating in mappings.

To dispatch the reasoning tasks generated by a Distributed Reasoner to the responsible reasoners, the Reasoning Propagator component refers to the Reasoning Manager and either dispatches reasoning to the local Distributed Reasoner or sends out a request of reasoning service to the corresponding external DRP.

Jump to top

Implementation

The described DRAGO architecture has been implemented for the case of OWL ontologies. For expressing semantic mappings between OWL ontologies we use a C-OWL. According to C-OWL, mapping consists of references to the source and target ontologies and a series of bridge rules relating concepts between these ontologies. Due to the limitations of introduced distributed tableau algorithm among the possible C-OWL bridge rule types DRAGO supports the use of Equivalent, Into, Onto rules connecting defined (atomic) concepts.

A Distributed Reasoner was implemented as an extension to an open source OWL reasoner Pellet. Originally, Pellet parses OWL ontology to a Knowledge Base (T-box/A-box). To satisfy the needs of DRAGO we extended a Pellet's Knowledge Base with a M-box containing parsed C-OWL mappings. Other extensions of Pellet were done by adding a Bridge Expansion Rule to the core tableau algorithm in order to transform it to the distributed tableau. The Bridge Expansion Rule rule is called for every node created by the core tableau algorithm and consist in finding such bridge rules in the M-box that are capable of importing new subsumptions from mapping-related ontologies.

DRAGO reasoning platform is written in java and consists of two core packages: (1) a reasoning peer, DRP, and (2) a client, called DRPConnector. Both applications have opened API so that external java-applications can easily invoke (start/stop/reason) DRAGO functionality.

DRP plays a role of reasoning server. Being started, it opens a socket on a specified port and listens for incoming reasoning requests. Requests are send/received over the TCP/IP network in accordance with a simple text-based protocol. DRP is a multi-threaded application, thus it can service multiple simultaneous requests from users. To simplify the communication with DRP and "hide" from a user unnecessary awareness of the communication protocol we have developed the DRPConnector application, which serves as a middleware between user and a certain reasoning server. Moreover, a DRP itself utilizes DRPConnector functionality in a Reasoning propagator block.

Starting multiple DRPs on different hosts forms a DRAGO network of distributed reasoning peers.

Jump to top