Drawing OWL 2 ontologies with Eddy the editor

1. Introduction

In computer science, an ontology is commonly defined as a specification of a conceptualization, that is, a formal description of an abstract, simplified view of a certain portion or aspect of the world [24,25].

To provide formal representations of such views, ontologies have to be specified in a well-understood language, with mathematical-based syntax and semantics. Ontology languages are thus usually rooted in some kind of logic, which allows for automated reasoning over them, i.e., automatic inference of implicit knowledge from the ontology specification. Among the main proposals advanced over the years, we recall those relying on first-order logic [18,31] and its extensions [40], Description Logics (DLs) [3], frames [23,33], production rules [46], Datalog and rule-based languages [4,7,32]. In particular, ontology languages based on DLs have become very popular, especially in the context of the Semantic Web [55]. Indeed, OWL 2 [28], which is the current release of the W3C standard Ontology Web Language, has its logical underpinning in the DL SROIQ ( D )  [11,30]. DL and OWL ontologies allow for representing the domain of interest in terms of concepts (a.k.a. classes), their attributes (a.k.a. data-properties), and binary relations between them (a.k.a. object-properties). Formal axioms involving those elements define the conceptualization by specifying the domain rules at an abstract level.

Another crucial property of an ontology is that it is shared, i.e., the representation it provides is agreed upon by all its users, so that it can act as a reference model across groups of people, communities, institutions, and applications [60]. Clearly, for an ontology to be shared, all the ontology users should be able to understand and exploit it, but this turns out to be not always easily achievable. In recent years ontologies have been introduced in several application contexts such as biomedicine, life and environmental sciences, e-commerce, e-government, cultural heritage [58]. Typically, people operating in these contexts are not able to easily interpret the logic-based formalisms through which an ontology is usually expressed and to completely exploit reasoning services over it, which instead they tend to consider simply a shared vocabulary.

Recently, we have experienced the above problem in various projects carried out in collaboration with industrial partners or public organizations (see, e.g, [1,2,54]). In these projects we have conducted an extensive ontology modeling activity and we have developed significantly large and complex ontologies, by working in collaboration with domain experts, who, in many cases, interacted with ontologies and languages like OWL for the first time. Our experience confirmed that modeling ontologies in contexts such as these can be very difficult if the representation is given in terms of logic formulas and by relying on tools designed for logicians. This turned out also to be an obstacle for transferring competences to our industrial counterparts, which wanted to take over the ontology development and management in the middle/long run, and to this aim asked for simple and user-friendly mechanisms for ontology representation.

To cope with the above problems, within our project activities we started the design and development of a new tool that could guarantee both formal specification of ontologies and their easy design and comprehension by our industrial counterpart. The result of our research investigation and implementation effort is Eddy,1

In Eddy ontologies are specified in Graphol3

The basic elements of our language are borrowed from the Entity-Relationship (ER) model [10], and our tool offers services, such as diagramming and code generation functionalities, which are typical of environments for database and software design drawings. Thus, both Graphol and Eddy are particularly suited for engineers, analysts, or designers in general who are used to describing requirements and designing systems through standard diagramatic conceptual modeling languages, like, e.g., ER or UML class diagrams [61].

At the same time, we notice that the syntax of Graphol mimics that of DLs, in the sense that, as in DLs, a Graphol ontology is a set of (graphical) inclusions between atomic or complex predicates, where the latter are constructed from the former through (graphical) operators. Thus, Graphol has a very short learning curve for DL or OWL experts.

An in-depth user evaluation study has shown that Graphol can be easily adopted by users knowledgeable in conceptual modeling but not necessarily in ontologies [39]. In these evaluation tests, Graphol has been perceived as difficult as classical UML or ER diagrams for simple ontologies, and has been recognized as more intuitive and simple for ontologies that require the usage of complex axioms (e.g., that go beyond UML or ER), with respect to a language that requires to express them through formulas.

We also note that the above user evaluation study has been conducted without the support of a tool specifically tailored to Graphol, since the aim of the test was to assess the effectiveness of the language, without being affected in this by any tool facility. However, the indications we have collected during this evaluation study have also highlighted the need of a dedicated environment for Graphol, and some feed-backs we obtained have been useful to start the development of Eddy.4

As already mentioned, the idea of using a graphical tool for knowledge representation is not new, and several proposals have been made during the years, in many areas of computer science, but none of them has succeeded in imposing itself as a reference graphical language for ontologies. Among them, the closest to our approach are those presenting UML-inspired languages and tools for the diagrammatic representation of OWL [6,17,26,42]. Differently from Eddy, none of them adopts a completely graphical language, but all require to complement the diagrammatic representation with textual formulas, in particular to encode complex OWL expressions. Other proposals that are not based on standard conceptual modeling languages, like [34,59], use structures such as graphs or concept diagrams to model ontologies. The notation used in these approaches is quite distant in nature from languages like ER or UML, and this turns out to be not completely suited in enterprise contexts. Also, these proposals have either been discontinued or are not able to completely capture OWL 2. We finally notice that popular ontology editing and engineering tools, such as Protégé,5

In the rest of the paper, we first briefly describe the Graphol language and provide an example of a Graphol ontology. This is the subject of Section 2. Then, in Section 3, we present Eddy. In particular, we show the main functionalities offered by our tool for drawing Graphol ontologies, and provide the algorithms it implements for ensuring that Eddy produces correct OWL 2 ontologies. Indeed, Eddy allows users to export Graphol ontologies in standard OWL 2 syntax, which is a crucial functionality to enable easy interaction with other OWL-based ontology editors and with DL reasoners.

In Section 4, we discuss the results of a user evaluation study we conducted to verify the effectiveness of Eddy, in which we involved people from the industrial world with some skills in conceptual modeling and database design, but without experience in ontology construction or engineering. Our tests show that Eddy has been perceived as an easy tool for ontology specification. Then, in Section 5, we illustrate the ongoing and future directions for the development of Eddy, whereas in Section 6 we discuss the most relevant related work, and in particular recall the main features of most popular ontology editors. We finally conclude the paper in Section 7.

OPEN IN VIEWER

Fig. 1.

Example of a Graphol ontology and its OWL 2 representation.

In this section we provide an informal general overview of the Graphol language, whereas for a complete description of its syntax and semantics we refer the reader to [39].

Graphol is a graphical formalism which has an inherent formal semantics based on DLs and resembles ER diagrams, but which is in fact able to fully capture OWL 2. We begin by showing an example in the top part Fig. 1, which models the world of comicbook characters and their abilities. In words, the ontology in the figure is saying that, among characters, there are Humans, Extraterrestrials, and Metahumans. Humans and Extraterrestrials are mutually disjoint, i.e., a human cannot be an extraterrestrial and vice-versa. Every character has a name, that is a string. Some characters are Villains, whereas others are Superheroes. A Superhero cannot be a Villain and has an archenemy. A character can have an Ability. Every ability has a name, which is a string, and some abilities are Superpowers. Finally, Metahumans are Humans with Superpowers. In the bottom part of Fig. 1 we provide a representation of the ontology through OWL 2 axioms specified in Functional-style syntax [44]. We remark that the two representations are equivalent, i.e., it is possible to define a transformation function preserving the semantics of the ontology and produce the OWL encoding from the Graphol diagram, and vice-versa. In particular, for this example we used Eddy to both draw the diagram and automatically produce the corresponding OWL Functional-style syntax specification.

One can see that Graphol’s representation of the main atomic predicates, i.e., the symbols constituting the alphabet of the ontology, is analogous to ER. Indeed, rectangles are used for atomic concepts (called entities in ER), which denote sets of objects, diamonds are used for atomic roles, which denote binary relations between objects (corresponding to binary relationships in ER), and circles are used for attributes, which denote relations between objects and values from value-domains, e.g., string and integer, represented in Graphol with rounded rectangles.

We recall that in OWL (and DLs) complex expressions can be built from atomic expressions (i.e., the atomic predicates) inductively with operators. For example, the union of superheroes and villains, denoted in OWL as ObjectUnionOf(:Superhero :Villain), is a complex concept expression constructed with the ObjectUnionOf operator applied to :Superhero and :Villain. Then, statements on how predicates (and expressions) are related to one another are specified through axioms. The most general form of an axiom is the inclusion between expressions. Obviously inclusions can be specified only between expressions of the same kind, e.g., two concept or two role expressions.

The basic idea behind Graphol is to represent the ontology as a set of inclusions, as in OWL 2, while preserving a graphical representation of it, given in terms of a directed graph. The nodes of the graph are atomic predicates or graphical operators, whereas the edges are solid or dashed arrows. The latter denote input to operators (as explained below), whereas the former denote inclusions.

For instance, in Fig. 1, the inclusion assertion between :Superpower and :Ability, corresponding to the OWL 2 axiom SubClassOf(:Superpower :Ability), is captured by the arrow between these two atomic concepts. For simplicity, inclusion edges between the same expressions and with inverse directions are denoted with a single solid edge with an arrow on both ends, which in fact corresponds to an equivalence between expressions.

Graphol expressions are either nodes representing predicates of the ontology (e.g., atomic concepts, atomic roles, etc.), or a combination of these nodes with nodes that represent operators. These latter ones in Graphol are of two kinds. The first are labeled blank and solid boxes, used for constructing role or attribute restrictions on the domain and range, respectively. We recall that the domain (resp., range) indicates the first (resp., second) component of a role or of an attribute. Here the label represents the type of restriction. For example, exists is used for existential restriction, which denotes the set of objects that occur in the domain (resp., range) of a role, and ( x , y ) is used for cardinality restriction, which denotes the set of objects in the domain (resp., range) of a role that occur in at least x and at most y links instantiating the role (similarly for attributes). In general, in Graphol we can add as many blank and solid boxes as needed to predicate appropriately on the domain and range of a role or attribute. The other operators are hexagons, which can be solid hexagons, representing a disjoint union, or blank labeled hexagons. In particular, blank hexagons can be labeled and, or, not, inv, and chain, respectively representing intersection, (non-disjoint) union, complement, inverse of a role (i.e., a role with inverted domain and range), and composition of roles. Expressions are built by connecting these nodes with dashed directed edges ending with a small diamond (called input edges). For instance, in Fig. 1, the domain of :has_ability is denoted via an existential restriction, i.e., through a dashed directed edge from the role :has_ability to a blank box labeled exists. In particular this expression is included through an inclusion edge in the concept :Character, which corresponds to the typing of the first component of the role :has_ability to :Character (i.e., only characters can have abilities). In OWL 2 this is specified as ObjectPropertyDomain(:has_ability :Character) (notice however that this can be specified in OWL Functional syntax also as SubClassOf(ObjectSomeValuesFrom(:has_ability owl:Thing) :Character), which is similar to the Graphol specification).

For a more complicated example, let us look at the inclusion used to specify that metahumans are humans with superpowers. In OWL 2 this is given through the axiom SubClassOf(:Metahuman ObjectIntersectionOf(:Human ObjectSomeValuesFrom(:has_ability :Superpower))), where ObjectSomeValuesFrom(:has_ability :Superpower) expresses the existential restriction on the domain of :has_ability, qualified to the concept :Superpower (which denotes the set of objects in the domain of :has_ability linked by this role to some instance of :Superpower). In Graphol, we construct this qualified existential restriction by linking through dashed arrows both :has_ability and :Superpower to a blank node labeled exists. This complex expression is in turn given as input to an and-labeled hexagon, together with the concept :Human, to take their intersection. The solid arrow from the concept :Metahuman to the intersection node finally depicts the wanted inclusion.

We also note that Graphol uses a special representation to draw functionality for roles and attributes, or inverse functionalities for roles. We recall that a role is functional (resp., inverse functional) if every object in its domain (resp., range) can participate only in one link instantiating the role (similarly for attributes). In particular, to represent a functional role (resp., attribute), Graphol uses a role (resp., attribute) node with a double blank border, to represent an inverse functional role, it uses a role node with a double solid border, and to represent a role that is both functional and inverse functional, as is the case for :is_archenemy_of in the example, it uses a combination of a double blank and solid border. In OWL 2 this corresponds to the two axioms FunctionalObjectProperty(:is_archenemy_of) and InverseFunctionalObjectProperty(:is_archenemy_of).

3. Eddy

In this section we introduce Eddy, the editor for the design and visualization of Graphol ontologies.

Graphol has been and is currently being used in various industrial and academic projects by teams of ontology designers for the design and maintenance of ontologies (see, e.g., [2]). In the absence of a custom editor, Graphol ontologies were specified with general-purpose tools for graph drawing. However, in order to exploit Graphol for ontology design to the fullest of its potential, it became clear that a tool specifically tailored to Graphol was needed. Furthermore, this was confirmed by evaluation tests [39] conducted on Graphol. Indeed, while Graphol proved to be easily understandable and received positive feedback, several difficulties were encountered during the editing tests, where an off-the-shelf editor for graphs was used, equipped with a special palette providing the Graphol symbols. These experiences gave way to the development of Eddy.

While designing the system we have kept in mind the most widely-accepted recommendations and principles of usability for human-computer interaction [15], e.g., Ben Shneiderman’s eight golden rules [57] and Jakob Nielsen’s ten usability heuristics [49]. For instance, we provide shortcuts for commonly-recurring tasks, support reversal of actions (undo), provide error handling and prevention, e.g., real-time syntactic validation of the ontology, display graphical and textual feedback for user actions, etc. Furthermore, to minimize the difficulty of adoption, the interface and default layout are similar to those of most popular commercial graphical editors, i.e., a central modeling canvas, surrounded by two sidebar areas where the user can access tools for editing, navigating, and inspecting the ontology.

Eddy is available as an open source project8

In the remainder of this section we will describe Eddy’s architecture and its features.

OPEN IN VIEWER

Fig. 2.

Eddy’s user interface with some of the basic plug-ins.

3.2. Drawing functionalities

Eddy offers a wide variety of drawing functionalities, from standard basic diagram editing features to more advanced features that are expressly tailored to the Graphol language. The former comprise, among others, bending edges or moving edge anchor points, resizing nodes, moving or editing labels, and cutting/copying, pasting or dragging portions of diagrams.

Graphol-specific drawing functionalities are provided by Eddy in order to aid users in rapidly performing commonly recurring tasks. These features are available through keyboard shortcuts and the contextual menus provided for each node in the diagram.

OPEN IN VIEWER

Fig. 3.

Eddy’s contextual menu for a role node.

For instance, as shown in Fig. 3, it is possible to choose the automatic composition of the domain or range of a role (resp., attribute), which results in a new blank or solid node labeled ‘exists’ being added in the diagram, linked to the selected role node through an appropriate dashed edge. Eddy also allows to switch the direction of the role, by automatically inverting the domain and range restriction nodes.

Moreover, it is possible to easily switch the label of a hexagon or a box from the contextual menu, which allows to instantly change the kind of operator represented by that node. This operation is syntactically controlled in real-time by the system: Eddy is provided with a context-aware mechanism that prevents the user from selecting an operator node type that would result in the composition of an invalid Graphol expression (e.g., an intersection node whose inputs are concept expressions cannot be switched to a role inverse, role chain, or complement node). A similar mechanism is used to control the automatic switch of the direction of edges: this can be accomplished only if the result is syntactically correct in Graphol.

Eddy is also equipped with an advanced feature for deleting Graphol expressions from the diagram. The user can select this purge function on the sink node of an expression, and all nodes that form the expression and that are not involved in other inclusions or expressions will be deleted from the diagram.

3.3. Separation between predicate and node level OPEN IN VIEWER

Fig. 4.

Eddy’s Info widget for a role node.

As said, Graphol allows to repeat the same predicate in the ontology through multiple predicate nodes. This is necessary because predicates that occur in numerous assertions in the ontology would otherwise be represented by a single node with numerous outgoing or incoming edges, resulting in layout and comprehension issues. This is compounded by the fact that in Eddy an ontology can be composed by several Graphol diagrams, so this representation through multiple nodes can occur even across different diagrams.

Imagine now that the designer wants to change the name of a predicate, or to impose the functionality on a role or attribute, which, as said in Section 2, requires the node to be rendered in a special way (by using a double blank border). Of course these changes need to be repeated for every occurrence of a node representing the predicate that is being updated by the designer. From a practical point of view, having to perform these tasks singularly is obviously time consuming and error-prone. In fact, in Eddy this is not necessary, since our tool allows the designer to perform the above changes only once, since it automatically propagates them throughout the ontology. This is obtained by virtue of a logical separation realized in Eddy between the predicate level, the one concerning with predicates as logical symbols, and the node level, the one concerning the representations of predicates as nodes in a Graphol diagrams. In general, seen at the predicate level a predicate is uniquely identified by its type and its name, whereas at the node level it might be represented by several nodes. The above “refactoring” tasks are thus performed at the predicate level, and propagated automatically at the node level.

In Eddy, this separation is put into effect in the Info widget, shown in Fig. 4 for the case of a role node, where the properties of the selected node are separated into predicate properties and node properties. Predicate properties include the name of the predicate and, in the case of a role or attribute, its properties. Any change to these properties is reflected in all nodes in the diagram that represent the predicate. Node properties instead include the ID of the node and its label. Changes to node properties are performed on, and limited to, the specific node. For example, changing the label of the node will modify the name associated to the node only, and will not affect other nodes representing the same predicate (if any). After the renaming, two alternative situations are possible: if no other node of the same kind and with the same label exists in the diagram, the node represents a new ontology predicate, whereas it represents a new occurrence in the diagram of an already existing predicate, otherwise (in this case, if the node denotes a role, it inherits the predicate properties of the other nodes representing the same predicate).

3.4. Syntactic validation functionalities

Eddy is equipped with validation functionalities to aid the user during editing, assuring that the constructed ontology does not present syntax errors. Since the expressiveness of Graphol coincides with that of OWL 2, this feature ensures that a Graphol ontology can be correctly exported in a standard OWL 2 syntax.

This check takes place in real-time while the user is modifying the ontology. Given the characteristics of Graphol, in Eddy a syntactic error can be produced only when drawing an edge between two nodes. Therefore, Eddy applies the check only when such an event takes place, and enables the change only if no errors are identified by the check.

OPEN IN VIEWER

Fig. 5.

Identities of most common Graphol nodes.

Roughly, the check performed by Eddy consists in a simple lookup of the Graphol syntactic rules, to verify whether they are violated by the update. This lookup is local, in the sense that Eddy needs to consider only the graphical elements involved in the update. More precisely, to establish whether an edge between two nodes can be added, Eddy needs to know the following information: the type of the edge to be inserted (i.e., whether it is an input or an inclusion edge); which are the source and target nodes between which the edge has to be traced (i.e., their shape and, if they are operator nodes, the label characterizing the kind of operator); the number and kinds of inputs to the target nodes. This last information is applicable only if the target node is an operator node and if the edge to be inserted is an input edge, and is needed to avoid exceeding the number and kind of inputs allowed for a certain operator node. Furthermore, Eddy needs to know the “identity” of the target and source nodes, i.e., whether they are concepts, roles, attributes, or value-domains.

Establishing the identity of a node is the complex aspect of the syntactic check. Indeed, while some nodes have a fixed identity (e.g., those that represent predicates of the ontology such as concept nodes and role nodes) others can change their identity according to the nodes they are linked to. We will refer to these nodes as id-modifiable nodes. For instance, a complement node, which is an id-modifiable node, can be used to build the complement of a role or the complement of a concept. In the first case the complement node assumes the identity of a role, while in the second, it assumes the identity of a concept. To denote the identity of a node we use the letters C, R, A or V, standing for concept, role, attribute, and value-domain, respectively. A combination of these letters indicates that the (id-modifiable) node can assume various identities, i.e., if the identity of a node is CV, it might become of identity C or V depending on how it will be linked to other nodes through input or inclusion edges. In fact, only the two combinations CRAV and CV are possible. The table in Fig. 5 shows the identities that some of the most common nodes in Eddy’s palette can assume, together with their default one, i.e., their identity if they are not linked to any other node of the ontology.

While the user is tracing an edge between two nodes, feedback regarding the correctness of the operation is displayed graphically by color-coding the target node when the mouse hovers over it. A valid connection is highlighted by surrounding the target node with a green frame, while an invalid connection, as shown in Fig. 6, is highlighted by surrounding the target node with a red frame, and with a message on the status bar indicating why the connection is not valid. In this second scenario, the edge will not be added to the diagram.

Figure 6 showcases an extremely simple example of the behavior of Eddy’s real-time syntactic validation, since both nodes that are being linked by the edge have a fixed identity. A more complex scenario is the one in which id-modifiable nodes are involved. Indeed, in this case to verify the compatibility of the nodes that the edge is connecting, their identity needs to be computed. For instance, consider the case in Fig. 7, in which a user is attempting to connect a role R to a not-labeled operator node, which would lead to constructing the union of concept nodes and of the complement of a role node. Eddy must in this case understand that the identity of the complement node is Concept, which is not compatible with the identity of the role node, which is clearly Role, and the syntax allowed for inclusion edges in Graphol.

In the following we describe (a slightly simplified version of) the technique used in Eddy for the syntactic check. Our tool in fact supports a refined and optimized version of the method described below.

OPEN IN VIEWER

Fig. 6.

Eddy’s syntactic check: Invalid inclusion (between a role and a concept).

OPEN IN VIEWER

Fig. 7.

Eddy’s syntactic check: Invalid negative role expression.

OPEN IN VIEWER

Algorithm 1

ComputeNodeID

To establish the identity of the nodes in a diagram, we use Algorithm ComputeNodeID (Algorithm 1). In the algorithm, n . ID denotes the identity of the node n in the diagram G , while defineID ( n , i ) is a function that determines the identity that the id-modifiable node n assumes when it is linked to a node with identity i. Establishing the identity depends on the Graphol syntax, and thus the function defineID executes some lookups to the syntax to return the identity of n. For example, if n is a union operator node, i.e., an or-labeled hexagon, and i = C , then defineID ( n , i ) returns C. Notice that the function defineID can even return CRAV or CV. For example, if n is a complement node with identity CRAV, and an input edge is traced from n to an intersection node with identity i = CV , then defineID ( n , i ) returns CV (indeed the complement node can now only become a concept or a value-domain node). We also establish a partial order between identities, stating that CV < CRAV , C < CV , R < CV , A < CV , and V < CV , whereas C, R, A, V are incomparable one another.

In essence, ComputeNodeID takes in input a Graphol diagram, annotated with node identities, and a node n, considers the Graphol diagram as an undirected graph (and treats both input and inclusion nodes in the same way), and performs a visit of the portion of such graph that is reachable from the node n by crossing only nodes with identity different from C, R, A, or V (i.e., when the algorithm reaches a node n with one such identity, it does not analyse other nodes reachable from n that have not been previously visited). To carry out the visit, the algorithm uses two sets of nodes, N and T , which are initially empty, and also initializes a variable id to the current identity of the input node. Starting from node n, the visit is carried out, and all encountered nodes whose identity is still not established are collected in the set N . When, during the visit, an edge ( n i , n j ) is crossed, the function defineID ( n i , n j . ID ) is used to establish the identity of n i on the basis of n j . ID . If such identity is lower, i.e., more specific, than an identity previously encountered, id is updated. This check is needed since the algorithm randomly selects the edge to visit at a certain iteration. For example, if we give, as input to ComputeNodeID, an intersection node having a union node and a concept as inputs, the algorithm might first select the edge connecting the intersection node to the concept, thus setting id to C. At the next iteration, the algorithm visits the edge connecting the intersection node to the union node, and finds that defineID returns CV (since it only looks at these two nodes). Without comparing this identity with that previously computed we would overwrite the right identity for the nodes belonging to the visited portion of the diagram.

When the visit is completed, the identity of all nodes collected in N is set to the value of id (i.e., the input diagram G has been updated).

As already said, when the user tries to draw an edge between two nodes in a diagram, Eddy checks the correctness of this insertion, based on the Graphol syntax and the identity of the two nodes, and adds the edge only if allowed by the syntax. Then, our tool executes ComputeNodeID to assign new identities to nodes, based on the presence of the new edge. In fact, if the identity of both the source and target node is different from CRAV or CV, there is no need to compute new identities, since they have been already established after a previous change in the diagram and cannot be modified by an edge insertion. Otherwise, it is sufficient to invoke ComputeNodeID only once, giving it as input either the source or the target node whose identity is not C, R, A, or V.

For our method to work it is also necessary to recompute identities of nodes when elements of the diagram are removed. In particular, when an edge is cancelled, ComputeNodeID is executed for both the source and the target node, i.e., it is invoked once with the source node as input, and once with the target node as input. If more elements are dropped together, ComputeNodeID is executed once for each node that is the source or the target of a removed edge (notice that in Eddy the removal of a node n causes that all the edges incoming in and outgoing from n are removed).

We remark that Eddy also supports the standard profiles of OWL 2.9

⁹

https://www.w3.org/TR/owl2-profiles/

These profiles are less expressive fragments of OWL 2, and the user can select one of them from a drop-down menu in the toolbar. When one of the profiles is selected, the nodes that are outside of its expressiveness will not be selectable from the Palette, and the syntactic validation tool will be run with respect to the syntax of the chosen profile.

Besides real-time validation, Eddy also provides a one-shot syntactic validation feature, available through a button in the toolbar. A pop-up window, shown in Fig. 8, notifies the user of the outcome of the test, and in case of a malformed expression or assertion, the user can choose to see the error in the appropriate diagram, ignore it and skip to the next one, or abort. Even though in principle a diagram designed in Eddy does not contain errors, situations as those described above can arise when the user wants to restrict to an OWL profile the expressiveness of an ontology initially written under the OWL 2 modality.

OPEN IN VIEWER

Fig. 8.

Pop-up window with feedback from the one-shot syntactic validation of the ontology.

OPEN IN VIEWER

Fig. 9.

Eddy’s system architecture.

OPEN IN VIEWER

Fig. 10.

Statistics of the participants: for Education, 1 = Bachelor Degree, 2 = Master’s Degree, 3 = Ph.D; Conceptual Modeling and Ontology Knowledge are on a scale from 1 to 5, with 1 indicating no knowledge.

Many of the functionalities we have developed in Eddy derive from user interactions with Graphol during the course of several industrial and academic projects, but also take into account the indications we have collected during a first user evaluation that we conducted on Graphol, described in [39]. These experiences, while confirming Graphol validity as a language for ontology design, have also highlighted the necessity of an ad-hoc editor for Graphol.

Following the previous positive experiences of the user test conduced on Graphol, we have carried out an evaluation on Eddy, in order to measure its usability for ontology editing by users who are already familiar with the Graphol language, specifically for finding possible weaknesses in the user interaction with Eddy.

The evaluation test was conduced with 25 users, chosen among the attendees of advanced academic and industrial courses on semantic technologies, in which they acquired some familiarity with methodologies and languages for ontologies (including Graphol). This number of participants is compliant with guidelines given in literature regarding best practices for usability tests for software tools, which indicate that five users is generally a sufficient number for qualitative tests, and roughly twenty is sufficient for a quantitative, or statistic, test [15,48]. All test participants come from the industrial world, and have some background in conceptual design, which is basically the know-how we assume for Eddy’s users. In Fig. 10 we recap some descriptive statistics about the participants regarding their age, highest completed education degree, their years of experience with ontologies, and their estimated knowledge of conceptual modeling and ontologies.

The structure of the test was the following:

OPEN IN VIEWER

Fig. 11.

Results of the Eddy user evaluation.

In Fig. 11 we show a synthesis of the results. The correctness of each performed task was graded on a scale from 0 to 4, hence the maximum possible total score for correctness, as well as clarity and easiness, for each user was 40. Moreover, the predetermined benchmark average for time per task was set at 3.5 minutes. The figure shows the distribution of the total results in terms of, from top to bottom, perceived easiness of the tasks, perceived clarity of the tasks, time, and correctness. Each box plot shows the full range of variation, from minimum to maximum, indicated by the whiskers, the median value, and the likely range of variation, indicated by the two boxes, which represent the quartiles, i.e., the three points that divide the dataset into four groups, each comprising a fourth of the data. The left box is delimited by the first quartile (middle value between the smallest value and the median) and the median; the right box by the median and the third quartile (middle value between median and highest value).

Clearly, the high correctness scores and the low times per task, compared to the benchmark time, produced by the users show a good ability in performing the required Graphol modeling tasks through the editor. The high scores for clarity and easiness also indicate not only that the users were able to understand what they were required to do in each task, but also that Eddy allowed them to achieve their goal comfortably.

OPEN IN VIEWER

Fig. 12.

Results of the ex-post survey.

The average results for the mandatory questions in the ex-post survey are represented in Fig. 12. We recall that for all four questions the scale is from 0 to 4, with 0 being the best possible value (note that question 1 involves the difficulty of the required editing tasks, and does not directly reflect the usability of Eddy). Clearly, these results reflect the fact that the experience with Eddy was absolutely positive for the participants to the test. Among the optional comments we collected, users particularly appreciated Eddy’s contextual menu and keyboard shortcuts, since they allow to easily specify some properties, which are instead perceived as complicated in the Graphol syntax. Suggestions for improvements included, for example, the possibility of importing OWL ontologies in Eddy, and providing more features for improving the alignment or distribution of the graphical elements in the diagrams.

Additional user feedback was obtained from the open questions in the post-test questionnaire and from a discussion with the users at the end of the test. This feedback indicated that the advanced drawing functionalities specifically tailored towards the Graphol language were particularly helpful in quickly carrying out several of the tasks in the test.

Eddy is currently under active development and we envision to extend its functionalities in several different directions. Some of these upgrades are currently being developed, and will be released shortly, others pose more significant challenges, and will require a more in-depth study. From the technical point of view, adding new features to Eddy is facilitated by its plugin-based architecture which guarantees extensibility and clear development direction.

A first upgrade we envision is the automatic drawing of some selected graphical patterns that correspond to classical conceptual modeling constructs, such as concept hierarchies, role typings, or mandatory participation of concepts into roles or attributes. Such functionality will enable the designer to select the pattern from a menu and thus have it automatically drawn in the ontology, ready for further customization.

An additional upgrade we envision for Eddy is the import of pre-existing OWL 2 ontologies. However, this problem is quite complex, and requires dealing with several issues. It will be necessary to develop a technique that processes the axioms that constitute an OWL 2 ontology, which do not provide any information regarding size and placement, and produce Graphol diagrams. To obtain an optimal result in terms of the final layout, this technique must consider not only aspects such as minimal edge intersection or distances between nodes [14], but also some semantic criteria, which have yet to be devised, that allow to group together elements of the diagram that have a high semantic proximity. We feel that this issue, while particularly challenging, is very important, because it will allow us to achieve full interoperability with the OWL 2 language and its tools.

Another interesting aspects we will address is scalability which is particularly significant when dealing with the representation of very large ontologies. This is an aspect that must be considered in the perspective of user comprehension and of ontology manipulation. It is indeed unfeasible when dealing with very large ontologies that feature hundreds or thousands of concepts to include them all in a single graphical representation. In this regard incorporating functionalities for the support of ontology modularization [22,53] would be crucial.

Finally, in the long run, we are also investigating the possibility of expanding Eddy in other directions. For instance, we envision the possibility of extending Eddy in order to fully embrace the Ontology-based Data Management (OBDM) paradigm [41]. This calls for supporting the design of other elements of an OBDM specification, and not only the ontology. Indeed, in Eddy we would need to allow the users to link Graphol ontologies with pre-existing data sources by means of mapping assertions. Therefore, we would need to provide an environment in which to specify such mappings, and also to validate them [35,38]. Furthermore, we would want users to be able to run queries over the generated ontologies and so coupling Eddy with external OBDM systems such as Mastro [9] and Ontop [8].

6. Related work

Certainly, the most widely-used among ontology design environments is Protégé, a popular open-source ontology editor and knowledge base framework [19], created at the Stanford University. It supports a variety of formats for ontology development, such as OWL 2, RDF(S), and XML schema, and provides a plug-and-play environment that favors application development and the creation of new functionalities through plug-ins that can change both the behavior and the appearance of the system. Popular reasoners for DLs and OWL are available as plug-ins for Protégé, which thus allows for exploiting the standard inference services offered by such reasoners. Protégé does not provide graphical functionalities for ontology specification, but rather its approach is to support the designer in the writing of the textual logical formulas that constitute the ontology. In this respect, Protégé is completely different from Eddy, and it is thus mainly devoted to users who are expert in ontologies and formal languages, rather than to users without such skills but familiar with diagrammatic languages for conceptual modeling.

Other well-known ontology design and engineering environments have been developed within the Eclipse platform.14

OWLGrEd [42] and VOM (Visual Ontology Modeler)17

Graffoo is a graphical notation for OWL ontologies, not based on UML [16]. In Graffoo ontologies are labeled graphs, which use several shapes for nodes and edges. Graffoo is specifically designed to capture OWL 2, but in order to do so, its visual representation is not completely graphical, as the constructs that are not directly supported by a native graphical element of the language are expressed through axioms in the OWL Manchester syntax, added as special nodes in the graph. Therefore the language suffers from the same difficulties discussed for previous tools regarding the need to embed logical formulas in the graphical representation. Graffoo currently does not come with an editing tool, but instead offers a palette for yEd, an open-source editors for graphs.

GrOWL [34] is a tool for visualizing and editing ontologies that, like Eddy, does not need to annotate the graphical representation with formulas. GrOWL, however, adopts a large number of symbols and distinguishes them also on the basis of their color and shading. Also, it uses DL notations for graph labels. Furthermore, the language did not evolve from OWL to OWL 2, and the project seems to have been discontinued.

While the above mentioned systems often attempt to provide some visual representation of ontologies, they are rarely successful in achieving a balance between the quantity of information that is provided to the user and the size and complexity of the overall representation, which is typically a two-dimensional graph.

Other tools and graphical notations instead focus uniquely on ontology visualization, and rely on different techniques to attempt to achieve this desired balance. The ontology models provided by these systems can be either two-dimensional or three-dimensional, and rely on visualization solutions such as multiple coordinated views [62], space-filling [56], degree of interest [12], and context focus [13]. Well-known examples of such systems are the OntoGraf18

Because these visualization tools lack any kind of ontology editing functionalities, they fall slightly outside the specific focus of this work, so we will not discuss them further.

In conclusion, our brief survey on the most popular ontology design and engineering environments highlights that no currently available tool provides features and mechanisms for a completely graphical specification of OWL ontologies through a notation that is close to standard diagrammatic languages for conceptual modeling used in the enterprise context. Indeed, some tools do not provide at all functionalities for the graphical editing of ontologies (e.g., [19]), others give only a partial support to this, requiring to complement the graphical representation with formulas (e.g., [42,63]), others adopt notations that are far from conceptual languages such as ER or UML class diagrams (e.g., [16,34]), and not always have a clear relationship with OWL (e.g., [59]) (of course, some tools present various of the above limitations). We also remark that often no formalized syntax is provided for the graphical representation adopted in some tools (e.g., [42]), and that other, more formal, proposals have been dismissed to date (e.g, [34]). Finally, many systems only allow for a graphical (in general partial) visualization of ontologies (e.g., [43]) and not for the editing thereof. Our tool Eddy is thus specifically aimed to fill these gaps, by offering a completely graphical ontology editing environment, based on the usage of an ER-styled language, called Graphol, which is equipped with formal syntax and semantics, and is equivalent to OWL 2 in terms of expressive power.

In this paper we have presented Eddy, an editor that provides advanced functionalities for designing syntactically and semantically correct OWL ontologies through their specification in Graphol, a visual ontology language equivalent to OWL 2. Eddy is an effective tool for ontology development, as shown by the user evaluation study which we have presented in this paper, and is currently used in several real-world projects. Eddy is open-source and its latest version can be downloaded at http://www.obdasystems.com/eddy.