- We first exhibit an ABox completion procedure for a given CF DInc knowledge 8 base K = (T ; A) with PTIME data complexity; the completion also serves as a basis for KB consistency checking.
Overview and Main Results. Ontology based data access (OBDA) is concerned with computing query answers over (possibly incomplete) data sources for which background knowledge about the data, commonly captured in an ontology, is available. The background knowledge enhances the understanding of the data source, provides additional query answers that may not be explicit in the data itself, and can also simplify query formulation.
To address scalability issues relating to the volume of data, many current approaches to OBDA focus on conjunctive queries (CQs) and ontologies based on DL dialects for which CQ answering is in AC0/PTIME with respect to data complexity. Moreover, to leverage advances in query processing in relational systems, approaches in which query answering can be reduced to SQL query evaluation over a relational encoding of the data are commonly sought.
There are two lines of investigation in this area that have received considerable
attention: (i) the perfect rewriting-based approaches in which the given CQ is rewritten
with the help of the ontological knowledge (typically formulated in one of the
DLLite family of logics) in such a way that the resulting query can be executed over the
plain data yielding the desired answers [
In this paper, we outline how a combination of query rewriting and data completion
can be used to enable OBDA directly over a relational data source in which background
knowledge is expressed in terms of CF DInc [
We solve this problem by introducing a novel technique based on combining query
rewriting with data completion. This is achieved in a three-step process by proceeding
(in a purely virtual sense) through the lens of a CF DInc ABox as follows:
8
1 This is an extended abstract for a paper to be presented at IJCAI 2016.
– We then define a query rewriting that produces a union of conjunctive queries Q0
from a given conjunctive query Q and T , and show that evaluating Q0 as a SQL
query over the above ABox completion, viewed as a relational database, computes
the certain answers of Q over K. A novel feature of this rewriting relates to the
generation of CQs to account for standard functional dependencies over relational
data sources, and is crucial in developing an OBDA framework that can entirely
avoid any need for object/individual invention or for “named nulls.”
– And finally, we show how a standard relational database schema can be naturally
captured as a (fragment of a) CF DInc TBox in a way that essentially obviates
8
the need for additional mappings between data sources and virtual ABoxes that are
typically utilized at this point, e.g., by [
Experimental results relating to the LUBM benchmark are also given that confirm the practicality of ABox completion by a direct manipulation of a relational data source. In particular, the results suggest that execution time for ABox completion in this way is comparable to the time required for raw data loading.
On the Utility of CF DInc in OBDA over Relational Data Sources. We illustrate this 8 with the use of a hypothetical (object) relational schema, given in Figure 1, in which single arrows denote named features, double arrows inheritance between tables, and where primary keys are underlined. We assume the schema derives from “create table” commands with primary and foreign key declarations, such as the following in the case of tables CLASS and CHAIR: create table CLASS ( dname STRING, num INT, iname STRING, room INT, time INT, primary key (dname, num), foreign key (dname) to DEPT, foreign key (iname) to PROF ) create table CHAIR ( name STRING, dname STRING, rname STRING, primary key (name), foreign key (name) to PROF ).
In a CF DInc TBox, tables such as CLASS correspond to primitive concepts, while 8 attributes such as dname and dept correspond to concrete and abstract features.2 Here are some examples of inclusion dependencies in the TBox for this schema: 1. To capture that table CLASS has attribute num and a foreign key to table DEPT:
Note that an (abstract) feature dept is introduced to capture the foreign key, and that it is realized, in the relational schema, by a (concrete) feature dname (implicit in the diagram in Figure 1). 2. To capture, respectively, the foreign and primary key declarations for table CHAIR together with a requirement that there is at least one tuple in the DEPT table that 2 CF DI8nc is a dialect of the CF D family of DLs, and, as such, replaces roles that are interpreted as binary relations with features that are interpreted as unary functions.
O student gpa name =5
ia inst /
mark INT o o / dept SK
reports CHAIR o class room time num / name
O head
dept / CLASS DEPT: values. so on. modeling.
Fig. 1. A RELATIONAL SCHEMA. refers to each tuple in CHAIR:
CHAIR v 9head 1 and 8head :CHAIR v DEPT: Note that we employ the PFD concept constructor available in all CF D dialects to capture a primary key. Its use in this case asserts that no distinct pair of CHAIR objects can agree on name-values. 3. To capture that name values in table PERSON are disjoint from name values in table
Note again the use of the PFD concept constructor which, in this case asserts that
no combination of a PERSON object and DEPT object can have the same
nameFuture work. We briefly discuss how our adoption of CF DInc enables further
opti8
mizations on generated SQL queries that are outlined in [
We also outline an avenue for further work in which techniques based on so-called
referring expressions recently proposed in [