Semantic Querying (SQ) is based on the automatic application of domain knowledge formalized as ontologies and rules, which semantically capture the underlying database design. An explicit semantic correspondence between the database schema and relevant domain ontologies is established by rules. Each domain ontology constitutes a highlevel model in the form of logical axioms using RDF(S) 1,2 and OWL 3 , which allows domain experts to pose queries in a semantic context that they are familiar with.
Existing SQ systems such as D2RQ [1], MASTRO [2], Incremental Query Rewriting (IQR) [3] typically allow database programmers to define mappings between relational schemas and domain knowledge bases, in the form of logical axioms or similar declarative constructs. These systems then translate the domain-based queries into SQL queries that can be directly executed on the data.
In recent work, HAIKU [4], [5] considers a different approach based on the deployment of Semantic Web Services on top of relational databases. This approach relies on suitable mappings written by the database programmers, allowing SADI [6] framework-based Semantic Web services to extract Hospital-Acquired Infections (HAI) data from The Ottawa Hospital (TOH) Data Warehouse (DW) [7]. One limitation of this approach is that service creation becomes labor-intensive and can be error-prone, because 1 http://www.w3.org/TR/rdf-concepts/ 2 http://www.w3.org/TR/rdf-schema/ 3 http://www.w3.org/TR/owl-overview/ it requires writing code for the service. This motivated us to investigate if code generation could be automated from declarative service descriptions, specifically by incorporating the necessary input and output parameters in appropriate places of generic Web service code-blocks.
In this paper, an architecture based on SQ is presented and its implementation is outlined with the goal of generating SADI Semantic Web service code automatically from their declarative input and output descriptions. The architecture enables access to relational data via the expressive rule language PSOA RuleML [8]. The automation facilitates Web service generation without human intervention and users are able to run queries over the generated services with the help of SADI query clients like Hydra and SHARE (see, e.g., [5]).
The methodology and architecture are novel: we are not aware of another system that allows the creation of Semantic Web services on top of relational data by leveraging an expressive rule language for semantic mapping and a firstorder logic reasoner for query rewriting.
The paper is organized as follows: we start with a brief description of SADI in Section II. A use case for service generation is shown in Section III and the work flow of our architecture is described in Section IV. Finally, in Section V some of the implementation challenges and an evaluation of the methodology are briefly discussed.
A. Basic SADI Ideas SADI [6] is a framework which utilizes Semantic Web standards and allows integration and interoperability among resources on the Web. SADI uses RDF[S], OWL for data representation and modeling, and HTTP-based recommendations (GET, POST) for interacting with the services.
The main distinguishing features of SADI services is that (1) they only exchange RDF, so "they speak the same language" (2) they can be automatically discovered and (3) orchestrated with the help of query clients like Hydra and SHARE (see, e.g., [5]).
III. EARLY-STAGE IMPLEMENTATION To show the advantages of our architecture, we walk through the generation of a simple SADI service that can query a database and retrieve results.
Our early-stage experiment comprises of a database schema, a corresponding domain ontology, service I/O descriptions modeled according to the ontology, and an SQL template generated from inputs to the reasoner.
A schema named PatientDiseaseDB is shown in Fig. 1. A relevant ontology describing the same domain is presented next. Here we describe a simple SADI service getPatientNameByDiseaseName which, upon receiving the name of a disease as input, provides the corresponding patients' names.
The input class is defined by a disease name with the name data property attached to Disease class which is expressed in Protégé syntax as Disease and name some string. The output class is defined by the patient names with the name property attached to the class Patient, which is attached to the Disease class by the isDiseaseOf property and is expressed as isDiseaseOf some (Patient and name some string).
Fig. 2 depicts the modeling of both the input and the output classes. The root node for both the classes is Disease. The solid arrows are labeled by the object property isDiseaseOf and by the single string-type data property name. Although the inverse property hasDisease is defined in the ontology, it is not part of the declarative descriptions, and denoted only by a dotted arrow.
Our reasoner, VampirePrime4 uses TPTP [9] as its primary input syntax. Hence, a translation is necessary to transform any non-TPTP syntax for generating SQL. This is accomplished by incorporating three translators into the architecture. The semantic mappings expressed in PSOA in Section IV-B can be translated into TPTP by using opensource tools such as the PSOA RuleML API [10] and PSOA2TPTP [11] (part of PSOATransRun5 ). The declarative input and output descriptions and the ontology are translated by the OWL API [12].
For example, the input and output declarative descriptions are translated by the OWL API-based translator into a single TPTP rule below ('--' labels conditions while '++' labels the conclusion, X, N, D are variables):
--p_Patient(X),--p_name(X, N),--p_isDiseaseOf(D, X) , --p_Disease(D), --p_name(D, "?"), ++answer(N)
The tuple N in the unary predicate answer denotes the patient tuple X's names who have the disease tuple D with a name "?", which is like a formal parameter and its actual values come from actual service inputs in run time. This rule is created by merging the input and output class based on the SADI principle that both the input and output class have a common root node.
VampirePrime generates the following SQL query template from the semantic mapping, ontology and the TPTP rule. Although in this specific case no reasoning is necessary, potentially VampirePrime can do very complex reasoning to rewrite queries. The template query contains the WHERE clause with the condition disease.name = "?", where the symbol '?' is extracted from the TPTP predicate p_name(D, "?") above. Due to space constraints, we refrain from documenting the complete Java code for the SADI Web service.
One of the most important tasks of our system is to extract the inputs from an RDF input instance and to place them precisely where they are needed. Once invoked, the Web service determines the string-type input value Arthritis, extracts it from the RDF input and replaces '?' with Arthritis in the WHERE clause, making the instantiated SQL query executable over the database: After the call and execution, the service returns the output RDF file containing a list of patient names John Doe, Bob, Alice etc. having Arthritis, each extracted from the tables in Fig. 1.
The following figure shows a graphical representation of the above RDF input and output instances:
The Web service generation process is best described by the main components (modules) of the architecture shown in Fig. 4.
Declarative service descriptions are composed of the properties along with the class names and various logical connectives from the ontology(ies) as shown by the input and output classes in Section II using Protégé syntax.
This module provides mappings between ontologies and databases using the Datalog sublanguage of the expressive Web rule language PSOA RuleML. The SQL queries and pseudo-RDF indicate how relational data is mapped.
The PSOA rule below embodies the semantic mapping of HAI-related data from TOH DW. Lines 12-18 essentially represent the SQL query while lines 1-9 and 19-23 capture the meaning of the pseudo-RDF. The relations among SQL queries and pseudo-RDF with these rules are exemplified in [4], [5] in detail.
The generation of SQL queries requires declarative service descriptions, semantic mapping of the database, and ontology (semantic schema) as the inputs. Our architecture will be using the IQR technique because it facilitates such SQL generation. The IQR technique takes the inputs and generates a (possibly infinite) number of SQL queries.
The service generator module generates Java code for the Web service. The service code consists of three parts: reading input RDF, business logic and writing RDF output. The code for reading input and writing output are generated based on the input and output class definitions, respectively. The service code when executed, reads input RDF and places all input values in appropriate places of the generated code as well as in the generated SQL template. Finally, the data drawn from the database is presented as RDF output according to the modeling of the output class. Thus, the module ensures automatic generation of a fully functional Web service code with no human intervention.
The open-source D2RQ platform uses a declarative language and employs a tool called D2R server, which uses a customizable D2RQ mapping to map database contents into RDF and allows users to issue SPARQL queries which are rewritten into SQL queries via the mapping. MASTRO is an ontology-based data integration tool. The mapping language in MASTRO allows for expressing Global-As-View mappings, answers unions of conjunctive queries, and it provides a sound and complete query answering algorithm for a rather restricted logic fragment. For our work, we plan to adopt the IQR technique which is based on a sound and complete algorithm that works with a full firstorder logic, but without a general termination guarantee and rewrites TPTP queries into SQL queries. Results from initial experiments show that simple SQL queries can be generated without problem. We plan to address complex query generation, case-by-case, in future.
Unlike D2RQ which exposes the database as a virtual RDF graph, in our approach, semantic mappings are written to map the existing ontology and the relational database. Any changes occurring in the database schema must be reflected in the mappings and such modifications are to be written by the database programmers. The mappings allow decoupling of applications from the database design. Should there be changes in design, the applications need not be changed provided that suitable mappings can be written for the new design. A detailed description of the semantic mappings is beyond the scope of this paper, we plan to address this issue in future.
For generating SQL queries by the VampirePrime engine, three inputs are required: semantic mappings, the ontology and the declarative descriptions. As VampirePrime can process only TPTP syntax, three translators are necessary for processing these inputs. We plan to reuse and modify existing tools such as the OWL API, the PSOA RuleML API, and PSOA2TPTP for the translation tasks.
In general, relational data are URI-free while any entity in a Web ontology is identified by a URI. Hence, efficient handling of URIs is important. As formulas in a Web rule language, PSOA rules can easily use entities with or without URI. We plan to use URI constructing functions for URI handling.
A list of HAI use cases has been identified in [5]. A thorough evaluation of our system can be performed by generating HAIKU SADI services that leverage these use cases and run on HAI data stored in the TOH DW.