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.
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 "
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
Jump to top
A DRP constitutes the basic element of DRAGO. The major components of a DRP are depicted in 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:
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.
- 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.
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
Jump to top
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
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
Jump to top