In this paper we present an in progress prototype for the graphical visualization and management of mappings for Ontology-based data access (OBDA). The tool supports the specification of expressive mappings linking a DL-Lite ontology to a relational source database, and allows the designer to graphically navigate them, according to various possible views, modify their textual representation, and validate their syntactic correctness. Furthermore, it gives preliminary support to the semantic analysis of the mappings, which aims to identify anomalies in the representation, like the specification of mapping queries that cannot return answers without contradicting the ontology. Such functionalities are currently being enhanced in our ongoing development of the tool.
Ontology-based data access (OBDA) is a data integration paradigm that can be synthesized as follows: given a system composed by an ontology, a source database schema, and a mapping between them, compute the answer to a query posed over the ontology, on the basis of the data stored at the sources [20,17].
Initial research on OBDA has identified “maximal” languages for ontologies and
queries that allow for first-order rewritable query answering, i.e., query answering
that can be reduced to the evaluation of a first-order query (i.e., an SQL query) over
the underlying data, organized in the form of an ontology ABox [
Whereas OBDA has been quite well-understood from the computational perspective
and various reasoning tools for it have been realized in the past years, so far very little
has been done to support the design and specification of OBDA systems. Indeed, even
though, on the one hand, off-the-shelf tools for the design and management of the
ontology level are available [
To meet the needs arising in OBDA, we developed a new tool to support mapping
design and specification. The tool, which we present in this paper, has two
distinguishing characteristics: (i) it allows designers to graphically visualize the mappings, and
(ii) it offers functionalities for semantic verification of the mappings. The graphical
visualization we propose turned out to be extremely useful in some real-life projects
we conducted (e.g., [
Semantic verification, instead, aims at identifying anomalous situations in which the mapping may cause unwanted behavior: for instance, it maps the same data into disjoint predicates, whatever the data at the sources are.
Our mapping editor is a stand-alone tool that has been developed within the MASTRO solution for OBDA. It is thus compliant with the framework adopted by MASTRO, i.e., it considers the source database to be relational, the ontology to be expressed in a
language of the DL-Lite family [
We point out that our tool is compliant with the R2RML standard, in the sense that it can export mappings in that format and is able to take an R2RML specification as input, provided that it encodes GAV mappings towards a DL-Lite ontology of the form described above.
The paper is organized as follows. In Section 2 we provide some preliminaries. In Section 3 we describe our mapping visualization model. In Section 4 we describe the support that the tool provides for both syntactic and semantic checks. Finally, in Section 5 we conclude the paper. 2
An OBDA specification is a triple hT ; M; Si, where T is an ontology, S is a source
database schema, and M is the mapping between T and S. More precisely, in our
mapping editing tool, T is a TBox specified in DL-LiteA;id;den [
(v), called the body of the mapping, is a first-order logic query over S with distinguished variables v (we will write such query in the SQL syntax), and
–
(w), called the head, is a conjunctive query whose atoms are of the form A(f (v0)), or P (f (v0); f 0(v00)), or U (f (v0); v00), where A, P , and U denote respectively an atomic concept, an atomic role and an attribute, f; f 0 are function symbols, v0; v00 are sequences of variables occurring in v, and v00 is a variable occurring in v.
M1 : SELECT S CODE, S NAME
FROM STUDENTS
WHERE DOB<=’1990/01/01’ M2 : SELECT S CODE,C CODE
FROM COURSES ; Student(st(S CODE)); name(st(S CODE); S NAME) ; takesCourse(st(S CODE); co(C CODE)) Such assertions relate a database schema containing the relational tables STUDENTS and COURSES to an ontology containing the concept Student, the attribute name, and the role takesCourse. M1 is a mapping assertion that in its body selects, from the table STUDENTS, the code (variable S CODE) and the name (variable S NAME) of students whose date of birth (variable DOB) is after December 31, 1989. For each tuple returned by its body, M1 builds an object term of the form st(S CODE), representing an instance of the concept Student, and an object/value pair representing an instance of the attribute name, which is composed by such object term and the value denoted by the variable S NAME. Similarly, M2 is a mapping assertion relating the relation COURSES to the role takesCourse. More precisely, from each tuple constituted by the code of a student (variable S CODE) and the code of a course she takes (variable C CODE), M2 builds a pair of object terms (st(S CODE),co(C CODE)), where co is a function symbol used to build object terms representing courses taken by students. Such a pair represents an instance of the role takesCourse.
The mapping editor we present in this paper is able to process mapping assertions written in the R2RML syntax. R2RML is the W3C standard to specify how RDF triples can be built starting from data stored in relational databases by means of so-called triple-maps. Actually, our mapping language is a subset of the R2RML standard, as shown by the following example.
Example 2. The mapping assertions M1 and M2 given in Example 1 can be represented in R2RML by means of the triple maps <#M1> and <#M2> described below. <#M1> rr:logicalTable <#Table1> rr:subjectMap [ rr:template "http://uniroma1.it/st/{S_CODE}" rr:class ex:Student ]; rr:predicateObjectMap [ rr:predicate ex:name rr:objectMap [rr:column "S_NAME"] <#M2> rr:logicalTable [ rr:tableName "COURSES" ] rr:subjectMap [
rr:template "http://uniroma1.it/st/{S_CODE}" ]; rr:predicateObjectMap [ rr:predicate ex:takesCourse rr:objectMap [rr:template "http://uniroma1.it/co/{C_CODE}"] <#Table1> rr:sqlQuery """
SELECT S_CODE, S_NAME FROM STUDENTS
WHERE DOB <= ’1990/01/01’ """.
We note that function symbols used in our language to build object instances are replaced in R2RML by template URI definitions. 3
This section introduces the visualization functionalities provided by our tool. The visualization is designed according to the following goals: 1. graphically represent a single mapping assertion; 2. graphically represent all the mapping assertions involving a given ontology predicate; 3. graphically represent all the mapping assertions involving a given relational table of the source database; 4. provide the user with the capability of editing the textual representation of a mapping assertion.
Figure 1 presents the user interface of our tool. The window displayed by the figure contains: (i) a menu bar in the upper side, with only the item File, through which it is possible to access the functionality that initializes the MASTRO system, save modifications on mapping assertions, and export mappings in the R2RML format; (ii) a tabbed pane in the left side, containing three tabs, namely, Ontology (which shows the list of all the predicates in the ontology alphabet, grouped into CONCEPTS, ROLES, and ATTRIBUTES) Mappings (which lists the IDs of all the mapping assertions) and DB (which lists all the tables in the source database); (iii) a text area in the bottom side, which is used to edit the head and the body of a mapping assertion, and which can be shifted to the right side of the window; (iv) a frame in the center, which provides the actual mapping visualization according to one of the modalities described in the following; and (v) an outline of the central frame in the left bottom corner.
As shown in the figure, colors used in the graphical representation of ontology predicates are as in Prote´ge´. In particular, concepts are denoted by orange ellipses, roles by blue rounded rectangles, and attributes by green rounded rectangles. The overall visualization is built by means of the Java open source graphic library JGraphX.
According to the objectives mentioned at the beginning of this section, our tool allows users to visualize mapping assertions by selecting one of three different views, called mapping-centered, ontology-centered, and source-centered, respectively. Each such view is conceived as a directed, layered graph, which actually traces the layers of an OBDA system. More in detail, each such graph is organized according to the following six layers (listed starting from the upper one): 1. the ONTOLOGY layer, in which a node represents a predicate in the alphabet of the ontology. 2. the OBJECTS layer, in which a node represents an object built from data in the
DATA layer, 3. the MAP layer, in which a node represents the head of a mapping assertion, 4. the DATA layer, in which a node represents a column of the result set retrieved by an SQL query in the body of a mapping assertion, 5. the SQL layer, in which a node represents an SQL query in the body of a mapping assertion, 6. the TABLES layer, in which a node represents a table in the source schema.
Mapping-centered view. This view aims to reach the first of the above visualization goals, i.e., representing a single mapping assertion once the user selects its ID in the MAPPINGS tab (see Figure 1).
The nodes and connections allowed in this view are listed below: – Each node in the ONTOLOGY layer can be either a predicate node or an propertyargument node. A predicate node represents a concept, role, or attribute occurring in the conjunctive query in the head of the mapping, and is depicted as described above. Every predicate node representing a role or an attribute S is connected to a property-argument node for each occurrence of an atom with predicate S in the head of the mapping assertion. These nodes have the shape of a triangle, have the same color of the predicate node to which they are connected, and are labeled with the string ’D/R’, which stands for predicate domain and range. Intuitively, they are used to distinguish the first and the second argument of an atom with predicate S. Indeed, each such node has two incoming edges by lower layers: the one ending in its left-hand side connects the node with the term occurring in its first argument, whereas the one ending in its right-hand side connects the node with the term occurring in its second argument. – Each node in the OBJECTS layer represents a term of the form f (v) occurring in the right-hand side of the mapping assertion. The label of each such node has therefore the form f(alias1,...,aliasN), where alias1,...,aliasN are the aliases in the target list of the SQL query in the left-hand side of the assertion. The nodes in this layer are linked either to concept nodes or to propertyargument nodes in the ONTOLOGY layer. Intuitively, in the first case OBJECTS nodes instantiate a concept, whereas in the second case they instantiate the role or the attribute linked to the property-argument node. In this respect, we notice that the connection with property-argument nodes relative to attributes can be only towards their left-hand side. – The node in the MAP layer represents the head of a mapping assertion and is labeled with the ID of the mapping assertion. The node in this layer is linked to each node in the OBJECTS layer. – Each node in the DATA layer represents a field of the target list of the SQL query in the body of the mapping assertion and is labeled with the SQL alias of such field. Every node in this layer is linked either to the node in the MAP layer or directly to property-argument nodes in the OBJECTS layer. In this latter case, the propertyargument nodes are in turn linked to a node representing an attribute. – The node in the SQL layer is labeled with ’SQL’ and represents the body of the mapping assertion. The node in this layer is linked to each node in the DATA layer. – Each node in the TABLES layer represents a table in the data source referenced by the body of the mapping assertion and is labeled with the name of the table it represents. All the nodes in this layer are linked to the node in the SQL layer.
To access the textual specification of the mapping, the user can click on the nodes in the SQL and MAP layers. In this way she visualizes in the text area in the bottom side of the window the body and the head of the mapping assertion, respectively. The text area can then be edited to modify the mapping.
When a node in the ONTOLOGY layer is double-clicked, the tool switches to the ontology-centered view relative to the selected node; similarly, by double-clicking a node in the TABLES layer, the corresponding source-centered view is presented.
When the node in the MAP layer is double-clicked, all the nodes in the OBJECTS layer are shown together with the edges linking them to the predicates that they instantiate. The user can visualize the result of some simple reasoning over the mapping assertion. For example, when a node X in the OBJECTS layer is clicked, the tool highlights all the edges in the paths starting from the node(s) in the DATA layer representing the data used to build the object associated to X and ending in the node(s) representing the predicates instantiated by the object associated to X . Something similar can be done with the nodes in the DATA layer.
Ontology-centered view. This view aims to reach our second visualization goal, i.e., representing all the mapping assertions involving a given predicate, once the user selects it in the ONTOLOGY tab (see Figure 2).
The nodes and connections allowed in this view are listed below: – The node in the ONTOLOGY layer represents the predicate on which the view is centered. If the node represents a role or an attribute it is also linked to a triangleshaped child node (of the same color) with label ’D/R’. – Each node in the OBJECTS layer represents an object built by mean of a function symbol, analogously to nodes in the OBJECTS layer of the mapping centered view. Also connections towards nodes in the ONTOLOGY layer are done in the same way, and obviously depend on the kind of predicate the view is centered on. – The MAP, DATA, SQL, and TABLES layers are as in the mapping-centered view, but in this case they are representing more than one mapping. Therefore, both the MAP layer and the SQL layer may contain more than one node, i.e., a node for each mapping assertion that involves the predicate on which the view is centered. Also, each node in the TABLES layer can be connected to more than one node in the SQL layer, if the table it represents occurs in more than one SQL mapping query of interest for the predicate on which the view is centered.
As in the mapping-centered view, the user can click on a nods in the SQL or MAP layer to visualize, and also edit in the text area, the body and the head of a mapping assertion. Again, the switch to other views is possible by double-clicking nodes in the MAP and TABLES layers, and some path-based visualization functionalities are allowed in a way similar to the ontology-centered view.
Source-centered view. This view aims to reach the third of our visualization goals, i.e., representing all the mapping assertions getting data from a table selected by the user in the DB tab (see Figure 3).
The nodes and connections allowed in this view are listed below: – There are no nodes in the ONTOLOGY, OBJECTS and DATA layers. – Each node in the MAP layer represents the head of a mapping assertion and is labeled with the ID of the mapping assertion. – Each node in the SQL layer is labeled with “SQL” and represents the body of a mapping assertion. The nodes in this layer are linked to the related node in the MAP layer. – The node in the TABLES layer represents the table on which the view is centered.
This node is linked to all the nodes in the SQL layer.
Visual functionalities similar to those described for the other views are available also in the mapping-centered view. 4
In this section, we present the functionalities currently provided by our tool for mapping editing support. In particular, we describe some features that help the mapping designer to fulfill a correct specification by identifying possible flaws in the mappings.
We consider two categories of problems: syntax errors and semantic anomalies. Issues of the first kind obviously refers to an incorrect use of the mapping syntax, whereas problems of the second kind concern situations in which, despite its syntactic correctness, the mapping specification may be considered somehow logically incoherent. We point out that we can safely assume here that the other components of the OBDA system we are managing do not present similar problems, since they are checked through the use of other tools that are part of our OBDA solution. In particular, we can assume that the ontology is a legal DL-LiteA;id;den TBox, i.e., it is syntactically well-formed, and also that it does not present semantic anomalies, i.e., it does not contain unsatisfiable concepts, roles, or attributes4.
Among syntax errors, we observe that those that can be more frequently found in mappings assertion specified without any support are: (i) the presence, in the head query, of predicate atoms that do not belong to the ontology alphabet, often simply due to misspellings; (ii) the use, in the head query, of variables that do not occur in the target list of the SQL body query; (iii) the presence of syntactic errors in the SQL query. In our tool, we are able to identify most of the syntax errors through a dedicated parser, which, for example is able to find out and report the user with all errors of kind (i) and (ii) above. As for SQL syntax verification, we rely on the external parser provided by the DBMS managing the source data.
For what concerns semantic problems for the mapping, given an OBDA specification hT ; M; S i we say that a mapping assertion m 2 M is semantically anomalous if the answer to either the head query of m or the body query of m is “intensionally” empty. More formally, let m be the assertion ; , intensional emptiness of the head query means that the evaluation of the conjunctive query over every model of T is empty, whereas intensional emptiness of the body query means that the evaluation of the SQL query over every database instance for S is empty. Having one such query (or both) empty in the sense described above may be either useless or dangerous in our specification. Indeed, if is empty, the assertion m is useless, since it will never contribute to instantiating the ontology predicates. On the other hand, if is empty and is not, the assertion may lead to a contradiction, since the semantics of the mapping is imposing that the tuples returned by instantiate the ontology in such a way that is not empty, while the semantics of the TBox T is imposing the intensional emptiness of (cf. the examples given below).
We observe that the identification of semantic anomalies related to the emptiness of SQL queries requires to solve an undecidable problem. Even though approximate solutions to this problem could be adopted, in the current implementation of our tool we have restricted this capability only to the pinpointing of semantic anomalies concerning the emptiness of the head queries of mappings, i.e., conjunctive queries issued over a DL-LiteA;id;den TBox. If this is the case, we say the the mapping m is semantically anomalous with respect to T .
We observe that semantic anomalies of this kind may occur only in one of the following cases: – In the head of m, a concept, role, or attribute S occurs such that T j= S v :S. – In the head of m, some join variables occur in positions relative to predicate arguments that are entailed to be disjoint by T . For instance, consider an ontology that specifies that someone who is a Student cannot be also a Professor. Then the mapping assertion
SELECT S CODE FROM T1 ; Student(st(S CODE)); P rof essor(st(S CODE))
is semantically anomalous with respect to T . – The query in the head of m is entailed to be empty by a denial assertion in T . For instance, consider an ontology O in which the denial assertion 8x:(isP arentOf (x; x)) ! ? is used to specify the irreflexivity of the isP arentOf role. Then the mapping assertion
SELECT ID FROM T2 ; isP arentOf (p(ID); p(ID)) is semantically anomalous with respect to T . – The query in the head of m is forced to be empty by functional assertions over roles or attributes, or by identification assertions specified in T . For instance, consider an ontology T in which the functionality of the role bornIn is asserted. Then, the mapping assertion SELECT ID1,ID2 FROM T3 ; bornIn(p(ID1); w(ID2)); bornIn(p(ID1); k(ID2)) is semantically anomalous with respect to T . Indeed, it is easy to verify that, due to the use of the two different function symbols w and k in head of the mapping assertion, for every pair of values (ID1; ID2), the functionality of bornIn is violated.
Our tool identifies mapping assertions that are semantically anomalous with respect to the TBox through query containment checks. More specifically, the tool first properly converts disjunction, denial, functional, and identification assertions in conjunctive queries (possibly with inequalities), and then, for each of such queries, it verifies if there is a query in the head of some mapping assertion that is contained in it. 5
The mapping visualization model described in Section 3 is the result of the iterative
refinement of various proposals that have been tested and developed during some
industrial OBDA projects in which we have been recently involved (see, e.g., [
Our experiences also allowed us to identify main analysis functionalities for our tool. The relative implementation is still ongoing. In particular, we are working on the semantic analysis of SQL queries in the mappings, to discover properties and relations between them that are useful to prevent situations which may lead to contradictions (this process relies on the use of a first-order theorem prover).
Furthermore, we plan to also implement functionalities for the graphical editing of the mapping, which in the current release can be modified only in textual modality.
We finally remark that the graphical representation of mappings presented in this paper is independent of the ontology language used in the OBDA specification: that is, it can be used with ontologies that go beyond the expressiveness of DL-Lite. On the other hand, the semantic checks identified by our approach are actually tailored for the DL-LiteA;id;den language.
Acknowledgments. This research has been partially supported by the EU under FP7 project Optique (grant n. FP7-318338). 17. Lenzerini, M.: Ontology-based data management. In: Proc. of the 20th Int. Conf. on Information and Knowledge Management (CIKM 2011). pp. 5–6 (2011) 18. Neto, L.E.T., Vidal, V.M.P., Casanova, M.A., Monteiro, J.M.: R2RML by assertion: A semiautomatic tool for generating customised R2RML mappings. In: The Semantic Web: ESWC 2013 Satellite Events. pp. 248–252 (2013) 19. Ortiz, M.: Ontology based query answering: The story so far. In: Proc. of the 6th Alberto
Mendelzon Int. Workshop on Foundations of Data Management (AMW 2013) (2013) 20. Poggi, A., Lembo, D., Calvanese, D., De Giacomo, G., Lenzerini, M., Rosati, R.: Linking data to ontologies. J. on Data Semantics X, 133–173 (2008) 21. Rodriguez-Muro, M., Kontchakov, R., Zakharyaschev, M.: Ontology-based data access: Ontop of databases. In: Proc. of the 12th Int. Semantic Web Conf. (ISWC 2013). pp. 558–573 (2013) 22. Sengupta, K., Haase, P., Schmidt, M., Hitzler, P.: Editing R2RML mappings made easy. In: Proc. of the 12th Int. Semantic Web Conf., Posters & Demos Track (ISWC 2013). pp. 101– 104 (2013) 23. Venetis, T., Stoilos, G., Stamou, G.B.: Query extensions and incremental query rewriting for OWL 2 QL ontologies. J. on Data Semantics 3(1), 1–23 (2014)