In this paper we present a prototypical implementation of a graphical tool for creating and editing (DL-safe) SWRL rules. The tool uses a graphbased approach to model rules expressed in the SWRL language. Rules are built from concepts and roles defined in an OWL ontology. Such a knowledge base can be visualised and edited in a user-friendly interface. Moreover, the presented tool provides methods for graphical representation of data and results of reasoning performed with the Pellet engine. We present a process of creating a knowledge base of family relationships as an example case. Perspectives of our future work are also presented.
tively simple form (e.g. ontologies as vocabularies, rules as filters). The main reason
for this is because ontologies and rules are too complex to handle by an ordinary user
[
Since SWRL provides more powerful reasoning capabilities than OWL and some
of the ontologies can be transformed into rules (e.g. Horn-SHIQ [
The main goal of this paper is to present a graph-based tool, in which an untrained
user is able to construct a set of simple (DL-safe [
The paper is organized as follows. Section 2 presents the main overview of the proposed approach, a set of employed tools and related work. Section 3 describes a prototypical implementation with a demonstration of creating a simple knowledge base of family relationships. Section 4 contains concluding remarks and our future work. 2 2.1
Visualising data in the form of graphs is connected to a problem of knowledge
representation (KR). Many investigators have created standardized notations for KR
(Unified Modeling Language/Object Constraint Language (UML/OCL) [
Protégé OWLViz12 plugin – it creates a hierarchical view of the selected part of an ontology in the form of a directed graph. It does not allow manipulation of objects on the graph nor does it visualise SWRL rules.
Protégé Axiomé13 [
TopBraid Composer14 – it is a visual modelling tool designed to create and manage ontologies in the Semantic Web standards. It is based on the Eclipse15 platform and the Jena API16. TopBraid Composer offers drag-anddrop way of creating and editing OWL ontologies. It allows consistency checking and debugging of OWL Inference engine. Users are able to incorporate SPARQL rules (SPIN17) into the process of class definition to create some constraints.
Snoggle18 – a graphical SWRL-based ontology mapper. It creates directed graphs representing structures of source and destination ontologies and enables creation of mapping relations between concepts from both ontologies.
Those mapping relations are then converted into SWRL rules. 2.2
The main goal of this paper is to present a graph-based environment, in which a user can: load an ontology, create and edit SWRL rules, perform reasoning and obtain results. Moreover, an ontology, rules and data are represented graphically as directed graphs. Additionally, an ontology can be represented as simple (and calculated) taxonomies of concepts and both types of roles (datatype and object properties). As a result, we obtain a graphical representation of a knowledge base constructed from concepts, roles, rules and facts (data). The knowledge base can be easily understood by an ordinary user who tries to work with ontologies and rules. Our aim is to provide an easy-to-use and easy-to-understand tool which can be used in many domains where ontologies, rules and graphs can be employed to support a user’s work.
The process of rule creation consists of creating two graphs which represents two parts of a rule: the body (left hand side) and the head (right hand side). In the presented approach, rules are of the following form: if the body then the head. Both the body 12 http://protegewiki.stanford.edu/wiki/OWLViz 13 http://protegewiki.stanford.edu/wiki/Axiomé 14 http://www.topquadrant.com/products/TB_Composer.html 15 http://www.eclipse.org/ 16 http://jena.apache.org/ 17 http://spinrdf.org/ 18 http://snoggle.semwebcentral.org/ and the head consist of positive conjunctions of atoms that are defined in an ontology as classes (concepts), object properties (roles) and datatypes. Thus, the left hand side (LHS) of a rule should be perceived as conditional elements that need to be fulfilled in order to execute instructions written in the right hand side (RHS). The execution of a rule can add new statements to the given knowledge base in the form of new relations between objects and new classifications of them. For example, using rule (1) we can infer that a person which has a male child has a son.
? , ? , ℎ ℎ ? , ? → ℎ ? , ? , ? (1) In rule (1) , and are OWL classes, ℎ ℎ and ℎ are object properties and ? , ? are variables. By executing this rule we obtain a new relation between objects under both variables from rule (1) and a new classification of object under variable ? .
As mentioned before, we represent rules, an ontology and facts in a graphical form. Each of them is a different directed graph. Each graph consists of nodes and edges. The nodes are a graphical representation of OWL classes (or objects in data visualisation) whereas edges represent appropriate relations between classes (objects); or classes (objects) and datatypes. Usually, an object may belong to a number of OWL classes, for example an object of class belongs also to the following classes: and . In our method we decided to use the most detailed class, which is often represented as the most bottom concept in the taxonomy of OWL classes. The rest of the applicable classes are shown in a tooltip after moving the mouse above the object. Moreover, a user can choose which class she/he wants to see on a graph. The same approach is applied in the object and datatype property taxonomies. An example of choosing a visible class is presented in Figure 1.
When loading an ontology, we can obtain two kinds of visualization. The first one is a Protégé-like view of taxonomies as trees. We provide three trees: the taxonomy of classes, the taxonomy of object properties and the taxonomy of datatype properties. The second visualization type is a graph-based view in which taxonomies are represented as directed graphs. Since a (rooted) tree is a special kind of directed graph, the visualization in both types is very similar. The main difference between them is that, in the graph mode, we can manipulate the graph structure by using specialised layouts or by manual rearrangement. Both types of OWL classes visualisation are presented in Figure 2.
Our graph-based editor supports the reasoning performed by the Pellet engine (see
Section 2.3). Results are presented to a user as a new graph of objects or as a pair of
graphs representing calculated taxonomies of classes and object properties. Moreover,
a user can check the consistency of an ontology and verify results obtained from
ontology- and rule-based reasoning.
In the presented graph-based editor we apply the Semantic Web Rule Language with
its syntax and semantics to read/write rules from/to an ontology. We employ the
OWL Web Ontology Language version 1.1 as a way to express the semantics of a
given domain. SWRL Built-ins [
We employed the OWL API19 tool to parse and write OWL ontologies. The Pellet20 engine is used as an OWL and SWRL reasoner. As a result of reasoning we can: check the consistency of an ontology and rules, calculate taxonomies, obtain potential 19 http://owlapi.sourceforge.net/ 20 http://clarkparsia.com/pellet/ inconsistences and infer new facts. In the editor, we can visualise an ontology before and after the calculation of taxonomies. Additionally, we can obtain a graph of facts before and after the reasoning process.
Visualization uses two Java libraries: Gephi21 and Processing22. We use Gephi to manipulate graph structures. It is also responsible for managing the layout of the nodes on the graph. Nodes can be rearranged manually or placed according to their graph-based parameters (centrality, modularity, PageRank, etc.). We use Processing as a software sketchbook to create the views of an ontology structure and a set of facts, as well as to create the rule editor.
Our graph-based rule editor for SWRL rule bases is fully implemented in the Java language. 3 3.1
Our graph-based editor consists of three tabs: ontology view, rule creation graph and instances view. The ontology view tab shows a visualisation of an ontology. The user can select a hierarchical structure of classes, datatypes or object properties to be visualised. Every edge in this view represents a subClassOf or subPropertyOf relation from the ontology. Our system proposes a calculated layout of classes, however this graph can be manually rearranged in order to improve the user impression and understanding. The hierarchy of classes is represented as grey circle nodes connected with edges. Structure of object properties is represented as blue square nodes connected with edges, whereas data properties are represented as green triangle nodes also connected with edges. All edges in the ontology view tab reflect the subsumption relation between two nodes.
The rule creation tab consists of 3 parts: conditions side, which represents the body of a rule; conclusions side, which reflects the head; and the class hierarchy presented in a tree structure. In order to create a rule, a user drags a class from the Class Hierarchy tree and drops it onto one of the rule sides (conditions or conclusions side). She/he is asked for a variable name or a value, which indicates the added object. Class concepts are presented as circles on the graph, with their class name and variable (value) as their labels. Both datatype properties and comparisons of variables can be added by right clicking on an object on the graph and selecting an appropriate option. The system limits datatype properties to those which can be linked with the selected object type (the selected class is in the domain of that datatype property or the domain constraint does not occur). Datatype properties are displayed in the form of a triangle connected by an edge with the corresponding object. The name of datatype is shown on the edge, and its value as a label of the triangle. 21 https://gephi.org/ 22 http://processing.org/
Relation between objects (object properties) can be added in a similar manner. After selecting a node and right clicking the other node, a list of available object properties is presented. After selecting one of them, it is displayed as an edge between selected nodes. In order to save a rule, the user needs to select an option from the top menu (File, then Save as…). A user can choose to save the ontology combined with the created rules.
The instances tab visualizes individuals (facts) stored in a knowledge base. They are represented as purple rhombs connected with each other by edges (roles from the ontology). Individuals can have datatype properties, which are visualized in the same way as in the rule creation panel, by triangles. After the reasoning, objects can belong to many OWL classes. This fact is impossible to represent on a static graph, however we present a method to solve this problem. After moving the mouse above an individual, a tooltip with all inferred classes appears. User can select which class should be visible on the graph as a default one.
The graphical representation of particular elements, which is applied in our editor,
is presented in Table 1.
An example application of our tool is performed with an ontology describing family
relationships. We slightly modified an ontology developed by Christine Golbreich
presented in [
The main difference between the original family ontology and our version of it, is the addition of: • Classes: , ℎ ℎ , , ℎ , . • Object properties: ℎ , ℎ , ℎ ℎ , ℎ ℎ , ℎ , ℎ ℎ , ℎ ℎ .
• Datatype property: ℎ .
Since the aforementioned new elements of the ontology are self-explanatory we do not provide more detailed descriptions. The modified version of the family ontology was then loaded into our editor. In the tool we created rules which are responsible to obtain instances of the following: • Classes: ℎ , ℎ , ℎ , • Object ℎ , ℎ ℎ , ℎ ℎ , ℎ ℎ , ℎ ℎ .
In this paper, we present two rules created with our editor. Rule (2) asserts an instance of relation ℎ which reflects that children of siblings are cousins of each other (ℎ is defined as a symmetric property). Rule (2) is presented in Figure 3.
ℎ → ℎ ? , ? , ? ! , ℎ ? , ? ? , ? , ? ?
, , ℎ
? ! , "
? , ? !
Rule (3) asserts an instance of class ℎ and an instance of a role ℎ ℎ . The rule expresses that a father of our grandparent is our great grandfather. Rule (3) is presented in Figure 4.
ℎ → ℎ ? ,
? ? , ? ℎ , , ℎ # ℎ ? , ? , ? , ? , ? ℎ ? (2) (3)
Created rules need to be applied to the set of facts in the ontology. After the
reasoning process, executed by Pellet, a user obtains results presented in a new graph (in
contrast to the graph before execution). Thus, new relations between objects and the
classification of them are obtained. Figures 5 and 6 present two graphs: before
reasoning (Figure 5) and after reasoning (Figure 6). These figures represent a part of the
knowledge base to which rules (2) and (3) can be applied. Instances preceded by the
letter ‘M’ represent men and instances preceded by ‘F’ represent women.
In this paper we have demonstrated a tool which supports graph-based creation and
edition of SWRL rules. The tool provides a visualisation of an OWL ontology, SWRL
rules and data. The graph-based representation is very convenient and intuitive. It is
an initial implementation which supports the creation of SWRL rules in a graphical
manner. The work presented in this paper is based on our previous experiences with
graph-based representation of rules [
The developed graph-based editor can be used in many domains where ontologies, rules and graphs can be employed to support users in their work. Moreover, changes in a SWRL rule base can be made by business specialists without engaging an experienced programmer. As a result, the usual process of consultation between them is omitted or shortened in time. Thus, the tool can significantly increase their work’s efficiency.
In further work, we will implement a query method for searching a knowledge base in a graphical manner. Moreover, we will provide a relational database interface. As a result, a semantic query will be posed into an integrated environment which will include a relational database, a set of rules and an ontology. In this case any graph containing nodes and edges could be entered as a search phrase. The reasoning engine will search the whole knowledge base for a given set of conditions, and return all objects that meet the specified requirements.
Another desired feature is to support OWL 2, which contains profiles designed for reasoning with rules and query answering, the RL and QL profiles respectively. A method of comparison between inferred and non-inferred knowledge bases is also planned.
Finally, we are going to make our tool available online for download and use with
a free academic license (for non-commercial users) [
Acknowledgement. This work was supported by DS-MK 45-102/13 and 45-085/12 DS-PB grants.