Ontology Enabled Graphical Database Query Tool for End-Users

Transcription

1 Ontology Enabled Graphical Database Query Tool for End-Users Guntis BARZDINS 1, Edgars LIEPINS, Marta VEILANDE and Martins ZVIEDRIS Institute of Mathematics and Computer Science, University of Latvia Abstract. In this paper we show how semantic web technologies are used in a real application in the domain of national medical databases where an important technological gap between the legacy relation databases and OWL ontologies is bridged by the recently standardized UML profile for OWL. After data has been exported from multiple relational databases into a single shared RDF database structured according to an integrated OWL ontology there emerges a need for a convenient end-user query tools. We describe a fully graphical access to the exported data through the graphical front-end tool (named DEMO tool) based on the UML profile for OWL and SPARQL query language. Keywords. semantic web, ontologies, information system design, database design, RDF data stores, modeling languages, data semantics Introduction Semantic web technologies such as RDF and OWL are lately starting to find promising and somewhat unexpected applications also in the field of information system engineering which traditionally has been based on the SQL driven relational databases [1, 2]. Despite relative inefficiency of RDF databases and SPARQL [3] query language (compared to the more mature relational databases) the flexibility of RDF to directly integrate data with its conceptual model (OWL domain ontology) removes a historic barrier from the databases the end-users now can query data from the database themselves by knowing the OWL ontology only, rather than rely on the man in the middle (a programmer, who creates the application-specific user interface for the database) to reformulate the end-user queries into the SQL statements over the hidden, implementation-specific normalized relational database schema. The problem is that in the legacy relational databases the initial conceptual model of the domain (often modeled as UML class diagram or ER-diagram) tends to disappear during conversion into the normalized database schema thus leading to database being inaccessible for direct query by domain experts familiar only with the conceptual model. Additional benefit added by RDF and OWL is the hierarchical scalable URI namespace, which eases the integration of previously separate databases. Such integration is aided also by the rich and yet strictly formal semantics of OWL DL. The richness of OWL DL provides means for modular abstraction levels over narrower domain ontologies during the database integration such as subclassof, subpropertyof, 1 Corresponding Author: Guntis Barzdins, Institute of Mathematics and Computer Science, University of Latvia, Rainis Blvd. 29, Riga LV-1459, Latvia; guntis.barzdins@mii.lu.lv

2 sameas, equivalentclass, equivalentproperty and similar constructs. Meanwhile formal semantics of OWL DL and its sub-languages maintains complete computability of such expressive ontologies. In this paper through the simple example derived from the real-life case-study in the medical domain we demonstrate the data access benefits made possible by the above mentioned semantic web technologies. We are largely omitting details of the actual relational databases conversion into OWL ontology and RDF data this subject is already covered in detail in our paper [1], as well as in D2RQ related papers [4]. Therefore the focus of this paper is on the syntactic sugar for fully graphical representation of both the ontologies (OWL) and the query language (SPARQL) thus making them directly accessible to the end-users, as it has long been acknowledged that the rather verbose nature of RDF, OWL, URI and SPARQL default serialization formats makes them unsuitable for the direct manipulation by the end-users. By endusers here we do not mean casual web surfers, but rather the domain specialists, such as medical researchers, who need to extract various data subsets from the databases in their expertise domain. Methods for graphical SPARQL query formulation with user-friendly GUI have been discussed by other authors earlier [5]. There are already some tools developed that support graphical query formulation such as Tabulator [6] and Longwell [7]. Meanwhile these tools are mainly based on query formulation by exploration. One problem what can arise with this approach is that user must know which way to explore. If user does not know given ontology well (and the query tool does not provide appropriate ontological assistance) then it could also be hard to know precise path for exploration. In our approach we are trying to avoid this problem by relying on the graphical ontology as the central concept. The graphical representation of ontologies is defined by the recently adopted UML profile for OWL [7] standard, therefore the proposed graphical SPARQL query tool ( DEMO tool) is modeled along the same graphical primitives to provide an unified, fully graphical end-user interface. In Section 1 we illustrate the crucial role of UML profile for OWL and how data from multiple databases can be integrated into a single shared RDF database structured according to the integrated OWL ontology. In Section 2 we describe a graphical end-user friendly SPARQL front-end that makes exported RDF data easy accessible to the end-user familiar only with the domain ontology. To demonstrate our approach as an example we use two simplified medical databases Oncologic Disease register and Trauma/Injury register from the earlier case-study [9] which was inspired by Semantic Latvia vision [10]. 1. OWL Ontology and Preparation of RDF Data The database export to RDF data triples (so-called Abox the data part of the ontology) structured according to the given OWL ontology (so-called Tbox the schema part of the ontology, without data) is typically implemented through the mapping process illustrated in Figure 1. In this paper we are not elaborating this conversion in detail as it is already covered in other papers [1, 4]. Nevertheless, by Figure 1 we want to stress that the below discussed OWL ontologies and RDF data are typically obtained from the legacy relational databases.

3 Figure 1. The relation database to RDF/OWL mapping process The key enabling technique for the described approach is the UML profile for OWL [8] which formally is a syntactic dialect of the W3C standard Semantic Web ontology language OWL. The outstanding characteristic of this dialect is that from one side it is fully compatible with the OWL language used for describing semantic web ontologies, but from the other side it is compatible with the UML class diagrams widely accepted for the design of traditional information systems. Since UML OWL profile diagrams correspond to regular OWL ontologies, they can be universally exchanged with other semantic web tools (Protégé editor, RDF databases, reasoners, etc.) through the W3C standard OWL serialization formats such as OWL/XML or OWL/N-TRIPLES. In other words, UML profile for OWL allows to view UML class diagrams as OWL ontology diagrams under the assumption that UML class is perceived as OWL class and UML property is perceived as OWL property (details see in [8]). We will use a small but representative fragment of the medical ontology derived from the Oncologic Disease register and Trauma/Injury register in our earlier casestudy [9] as a running example for the rest of this paper. In Figure 2 the example ontology is presented in the form of UML class diagram. This diagram illustrates the key features we have found to be the most relevant when mapping legacy relational database schemas into OWL ontologies via UML class diagrams: Generally class attributes correspond to datatype properties in OWL, while associations between classes correspond to object properties in OWL. Although UML profile for OWL allows overriding this rule, in our casestudy it was not necessary. Subclass relationship (inheritance between classes in UML). Due to formal semantics of OWL DL, subclasses may be marked to be owl:disjointwith each other, or they may be left potentially overlapping. In Figure 2 Injury and Cancer are examples of disjoint subclasses of Disease while TransportAccident and BrokenBone are potentially overlapping subclasses of Injury. This difference is further illustrated by the data sample in Figure 4, where individual i00008 belongs to the subclasses TransportAccident and

4 BrokenBone simultaneously and therefore has attributes of both of these classes. Subproperty relationship ( redefines for association ends in UML). Along with subclass relationship, this provides a powerful mechanism for integrating overlapping ontologies from different abstraction levels. In Figure 2 the grey background highlights a portion of the integrated ontology which effectively is a high-level abstraction of the more fine-grained domain ontology fragments outside the highlighted area. Thanks to formal semantics of OWL DL, these various abstraction levels later will be usable also in queries (e.g., end-user may ask for Persons having any Disease, although the raw data for Persons might have links only to Injury or Cancer classes). Enumeration datatype. This is a widely used feature in legacy relational databases in UML it is depicted by <<enum>> class, which effectively enumerates all individuals belonging to this class. Enumeration datatype in OWL is supported through the owl:oneof feature. Figure 2. An example of medical ontology as UML class diagram The graphical ontology in Figure 2 corresponds to the OWL/N-TRIPLES serialization ontology shown in Figure 3. To execute this conversion one option is to rewrite the UML class diagram shown in Figure 2 into correct 2 UML OWL profile diagram supported by the Eclipse-based IODT (EODM) tool. This tool can save UML 2 For example, UML profile for OWL does not include redefines feature; in this example we model it as a subproperty although formally it should be modelled using restriction classes

5 OWL profile diagrams into the standard OWL/XML serialization further convertible into OWL/N-TRIPLES serialization (used in this paper). Unfortunately, the available IODT (EODM) tool has a rather limited functionality and therefore authors currently suggest using Protégé editor to manually convert between these two formats. < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < _:AX40XX5fXX3aXUA3. _:AX40XX5fXX3aXUA3 < < _:AX40XX5fXX3aXUA3 < _:AX40XX5fXX3aXUA0. _:AX40XX5fXX3aXUA0 < "head"^^< _:AX40XX5fXX3aXUA0 < _:AX40XX5fXX3aXUA1. _:AX40XX5fXX3aXUA1 < "neck"^^< _:AX40XX5fXX3aXUA1 < _:AX40XX5fXX3aXUA2. _:AX40XX5fXX3aXUA2 < "arm"^^< _:AX40XX5fXX3aXUA2 < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < <

6 < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < Figure 3. OWL/N-TRIPLES serialization of the ontology from Figure 2 Finally, Figure 4 shows some RDF data structured according to the example ontology shown in Figure 2 and Figure 3. In the scenario depicted in Figure 1 such data would come from the legacy relational database through the transformation defined by the source database schema and the target OWL ontology. Such transformation most conveniently can be implemented either as an SQL procedure in the original database with appropriate output formatting or as a mapping file for D2RQ tool [11]. < < " "^^< < < "36819"^^< < < < < < "Janis Liepa"^^< < < "Latvian"^^< < < < < < < < < < < < "1A"^^< < < < < < "A00.0"^^< < < "A00.1"^^< < < < < < "A00.9"^^< < < < < < "fell from rock"^^< < < < < < "true"^^< < < "arm"^^< < < < < < < < < < < < < < < < < < "Russian"^^< < < < < < "72256"^^< < < "Igor Valujev"^^< < < " "^^< < < < < < < < < < < < "victim"^^< < < "hit by car"^^< < < "head"^^< < < "false"^^< < < < < < < < < < < < "A01.2"^^< < < "A01.7"^^< < < < Figure 4. RDF data triples corresponding to the ontology shown in Figure 2 and Figure 3 The data sample in Figure 4 illustrates an important aspect of the OWL openworld semantics (mentioned already in the beginning of this section), which is different from the traditional closed-world semantics of SQL databases: individual i00008 via type relation belongs to two possibly overlapping classes BrokenBone and

7 TrafficAccident simultaneously this describes a case, where broken bone injury is a result of a traffic accident. This is a perfectly legitimate (and necessary) situation in OWL as long as the involved classes are not explicitly declared to be owl:disjointwith. This completes the steps required to present a database into the OWL/RDF format now the prepared OWL ontology and RDF data can be loaded into RDF database such as Sesame [12] and accessed through the SPARQL [3] queries as it will be discussed in the next section. Nevertheless there is one important aspect involved without which the whole setup would not work properly it is the need for reasoning (or entailment inference) support in the RDF database. Without that we would not be able to infer, for example, the RDF triple < < < which is entailed by the OWL DL formal semantics, but is not explicitly present among RDF triples in Figure 3 and Figure 4. Full OWL DL entailment power is available only in OWL DL reasoners such as Pellet which technically can be used also as a limited-size RDF database with SPARQL access. Meanwhile for pure data access there is no need for full OWL DL reasoning, much of which deals with enforcing constraints such as satisfiability, owl:disjointwith, and cardinality restrictions which we can assume to be already enforced by other means in the provided RDF data. Therefore for pure data access it is sufficient to enable only RDF Schema and direct type hierarchy inferencing, which is much faster and more scalable to large data sets (for example, in Sesame RDF database this kind of entailment inferencing is enabled by applying native-rdfs-dt or memory-rdfs-dt template during Sesame repository creation). As a side note lack of any reasoning support in D2RQ is the only reason why this otherwise convenient tool for on-the-fly SPARQL access to relational databases is not compatible with the approaches described in this paper. 2. Graphical Query Tool for End-Users As it was mentioned in the Introduction, the key idea of our approach is to use the OWL ontology as the only guidance for SPARQL queries over the RDF database. To query relational database with SQL one needs to know physical database schema. To query RDF database with SPARQL one needs to know RDF database structure a corresponding OWL ontology. Query: select?name?phone where {?p < < < < < < Query Results (1 answers): name phone =================================================== "Janis Liepa"^^xsd:string " "^^xsd:string Figure 5. SPARQL query executed over database of RDF triples from Figures 3, 4

8 Indeed we can formulate semantically clear queries in SPARQL using only the OWL ontology from Figure 2. For example, if we would like to find names and phone numbers of all persons having both an injury and a cancer, we could formulate this query in SPARQL by traversing the appropriate path in ontology Figure 5 shows the resulting SPARQL query and its execution result on the RDF triples from Figure 3 (ontology) and Figure 4 (data). Although it is now possible to formulate SPARQL queries as shown in Figure 5 manually from the ontology in Figure 2, the coding of such queries requires remembering of exact qualified URIs for involved concepts and is generally timeconsuming for the potential end-user. Therefore we have developed a graphical frontend for generating such SPARQL queries via same graphical primitives used by UML OWL profile representation of the ontology without the need for the end-user to digress into the textual SPARQL and technical RDF triples encoding of ontologies. This enables convenient querying by the end-user even in large ontologies which would otherwise be difficult to even comprehend textually. The main idea of our query construction tool is that user first selects concepts (classes) in the ontology that are involved in his query and after that just says that these concepts should be somehow connected. Then a shortest path algorithm finds several most probable connection paths between the selected classes and returns them to the user so that he can choose the correct path intended or narrow the search space by selecting classes defining a partial path manually, if none of the returned paths is appropriate. This way we tackle the problem that user must be somewhat familiar with the ontology (is able to read it) but does not need to know it very well. There are two main components in our query language a class (concept) and a link (relation, property) representing an association between two classes. When user starts to formulate a query, first of all, he chooses classes that will be involved in the query as shown in Figure 5. The user does not need to remember exact class names, as these are automatically retrieved by the DEMO tool from the RDF database (by a simple SPARQL query) and presented to the user as a drop-down list. Note that the same class from the ontology may be represented with more than one class-icon in the graphical query if different subsets from the same class need to be considered (e.g. Diagnoses related to Injuries and Diagnoses related to Cancer as illustrated in Figure 11). Figure 6. Choosing classes in DEMO tool

9 User can also draw links between the selected concepts (classes). The key idea of DEMO tool is that user can draw such links even between classes that are not directly connected in the ontology the mentioned shortest path algorithm computes the most probable full paths in the ontology and shows them in the dialogue box from where the user chooses the appropriate actual path for his query (Figure 7). If there are some additional classes in the selected path then these classes are automatically added to the graphical picture. Figure 7. Choosing links between classes in DEMO tool After user has selected all necessary classes and relations (selected classes and relations must form a connected graph) he can further narrow the query by optionally adding attribute conditions to some of the selected classes as shown in Figure 8. Figure 8. Adding attribute conditions in DEMO tool

10 After query has been formulated the next step is to get an answer. The tool could return as an answer a full table containing all attributes of all classes involved in the query. Meanwhile more often user is interested only in few attributes of few involved classes in this case user must select which attributes of which class he would like to see in the result table (Figure 9). Figure 9. Choosing class attributes for result table in DEMO tool At this point a SPARQL query is created from the designed graphical structure and is submitted to the RDF database for execution. After it has been processed by the RDF database the answer is received back and the result table is constructed as shown in Figure 10. The result table window includes also the actual SPARQL query constructed by the graphical query tool. Figure 10. SPARQL answers in DEMO tool

11 Of course, further user interface and functionality improvements could be added to the illustrated DEMO tool. The tool could be extended to cover more complete set of OWL and SPARQL features besides the core features demonstrated in this example. At present only classes are considered as selectable concepts but sometimes user might want to select also a concept that actually is an attribute. Another advanced example in Figure 11 illustrates use of inheritance to specify that only injuries that are both TransportAccident and BrokenBone should be considered. Figure 11. Advanced features in DEMO tool Our graphical query construction tool (a DEMO tool ) is built using GrTP tool platform [13] and transformation language LX [14]. Graphically formulated queries are translated into SPARQL and then queried to Sesame RDF database with RDF Schema and direct type entailment inference enabled through the native-rdfs-dt template. 3. Conclusion In this paper we have demonstrated a successful practical application of graphical semantic web technologies. The successful application relies on essential graphical techniques provided by UML OWL profile [8] both in ontology definition phase as well as in data access phase. The described project is work in progress, but even the current results provide highly useful fully graphical end-user interface with ontologies and data queries. Acknowledgments This work is supported by the National Research Programme projects "Multi- Disciplinary Research Consortium on Major Pathologies Threatening the Life Expectancy and Quality of Life of the Latvian Population" and Research and Adaptation of Semantic Web Technologies in Latvia

12 References [1] Barzdins, J., Barzdins, G., & Cerans, K. (2008) From Databases to Ontologies. In Cardoso, J., & Lytras, M. (eds), Semantic Web Engineering in the Knowledge Society. IGI Global, pp [2] Yuan, J., & Jones, G. H. (2007) Enabling Semantic Access to Enterprise RDB Data. In W3C Workshop on RDF Access to Relational Databases. (available at [3] SPARQL Query Language for RDF. W3C Recommendation (2008). (available at [4] Bizer, C., & Cyganiak, R. (2006) D2R Server - Publishing Relational Databases on the Semantic Web. Poster at the 5th International Semantic Web Conference (ISWC2006), November 5-9, Athens, GA, USA. (available at ISWC2006.pdf) [5] Athanasis, N., Christophides, V., & Kotzinos, D. (2004) Generating On the Fly Queries for the Semantic Web: The ICS-FORTH Graphical RQL Interface (GRQL). In the 3rd International Semantic Web Conference (ISWC2004), November 7-11, Hiroshima, Japan, pp (available at [6] Berners-Lee, T., et al. (2006) Tabulator: Exploring and Analyzing linked data on the Semantic Web. In the 3rd International Semantic Web User Interaction Workshop (SWUI 2006), November 6, Athens, GA, USA. (available at [7] Longwell project page. SIMILE Project (2006). (available at [8] Ontology Definition Metamodel. OMG Adopted Specification. Document Number: ptc/ , November (available at [9] Barzdins, G., Liepins, E., Veilande, M., & Zviedris, M. (2008) Semantic Latvia Approach in the Medical Domain. In Haav, H-M., & Kalja, A. (eds), Proceedings of the 8th International Baltic Conference (Baltic DB&IS 2008), June 2-5, Tallin, Estonia, Tallinn University of Technology Press, pp [10] Barzdins, J., Barzdins, G., Balodis, R., Cerans, K., et al. (2006) Towards Semantic Latvia. In Communications of the 7th International Baltic Conference on Databases and Information Systems (Baltic DB&IS 2006), July 3-6, Vilnius, Lithuania, pp (available at [11] Bizer, C., & Seaborne, A. (2004) D2RQ Treating Non-RDF Databases as Virtual RDF Graphs. In the 3rd International Semantic Web Conference (ISWC2004), November 7-11, Hiroshima, Japan. (available at [12] Broekstra, J., Kampman, A., & Harmelan, F.v. (2002) Sesame: A Generic Architecture for Storing and Querying RDF and RDF Schema. In The Semantic Web - ISWC 2002, volume 2342 of Lecture Notes in Computer Science, pp (available at [13] Barzdins, J., Zarins, A., Cerans, K., Kalnins, A., Rencis, E., Lace, L., Liepins, R., & Sprogis, A. (2007) GrTP: Transformation Based Graphical Tool Building Platform. In Proceedings of the MoDELS'07 Workshop on Model Driven Development of Advanced User Interfaces (MDDAUI-2007), CEUR Workshop Proceedings, Vol 297. (available at WS/Vol-297/paper6.pdf) [14] Barzdins, J., Kalnins, A., Rencis, E., & Rikacovs, S. (2008) Model Transformation Languages and Their Implementation by Bootstrapping Method. In LNCS, vol. 4800, Springer, pp