Ontology-based query answering (OBQA) has long been an important topic in applied and foundational research, and in particular in the area of description logics (DLs). Query answering has been studied for every major DL, but the most prominent use of DLs in query answering is based on the DLs of the DL-Lite family. In particular, these have widely been used in ontology-based data access (OBDA), e.g., to integrate disparate data sources or to provide views over legacy databases [3,14,4,9]. DL-LiteR is also the basis of the W3C OWL 2 Web Ontology Language profile OWL QL, which was specifically designed for OBDA applications [12]. On the other hand, research on query languages has led to a range of expressive features beyond basic pattern matching, e.g., by supporting navigational constructs or other forms of recursion. These developments have also a ected practical query languages. SPARQL 1.1, the recent revision of the W3C SPARQL standard, introduces significant extensions to the capabilities of the popular RDF query language [7]. Even at the very core of the query language, we can find many notable new features, including property paths, value creation (BIND), inline data (VALUES), negation, and extended filtering capabilities. In addition, SPARQL 1.1 now supports query answering over OWL ontologies, taking full advantage of ontological information in the data [6,5]. Thus, with the arrival of SPARQL 1.1, every aspect of OBQA is supported by W3C technologies. In practice, however, SPARQL and OWL QL are rarely integrated. Most works on OBDA address the problem of answering conjunctive queries (CQs), which correspond to SELECT-PROJECT-JOIN queries in SQL, and (to some degree) to Basic Graph Patterns in SPARQL. The most common approach for OBDA is query rewriting, where a given CQ is rewritten into a (set of) CQs that fully incorporate the schema information of the ontology. The answers to the rewritten queries (obtained without considering the ontology) are guaranteed to agree with the answers of the original queries (over the ontology). This approach separates the ontology (used for query rewriting) from the rest of the data (used for query answering), and it is typical that the latter is stored in a relational database. Correspondingly, the rewritten queries are often transformed into SQL for query answering. SPARQL and RDF do not play a role in this. In a recent paper [1], we took a fresh look on the problem of OBQA query rewriting with SPARQL 1.1 as our target query language. The additional expressive power of SPARQL 1.1 allows us to introduce a new paradigm of schema-agnostic query rewriting, where the ontological schema is not needed for rewriting queries. Rather, the ontology is stored together with the data in a single RDF database. This is how many ontologies are managed today, and it corresponds to the W3C view on OWL and RDF, which does This extended abstract summarises the recent results of the authors' paper Schema-Agnostic Query Rewriting in SPARQL 1.1 [1].
not distinguish schema and data components.4 The fact that today’s OBQA approaches separate both parts testifies to their focus on relational databases. Our work, somewhat ironically, widens the scope of OWL QL to RDF-based applications, which have hitherto focused on OWL RL as their ontology language of choice.
Another practical advantage of schema-agnostic query rewriting is that it supports
frequent updates of both data and schema. The rewriting system does not need any
information on the content of the database under query, while the SPARQL processor that
executes the query does not need any support for OWL. This is particularly interesting if a
database can only be accessed through a restricted SPARQL query interface that does not
support reasoning. For example, we have used our approach to detect an inconsistency of
DBpedia under OWL semantics, using only the public Live DBpedia SPARQL endpoint
at http://live.dbpedia.org/sparql (the problem has since been corrected).
The main contributions of our work are:
– We expressed standard reasoning tasks for OWL QL, including consistency checking,
classification, and instance retrieval, in single, fixed SPARQL 1.1 queries that are
independent of the ontology. It turned out that SPARQL 1.1 property paths are
powerful enough for OWL QL reasoning.
– We showed how to rewrite arbitrary SPARQL Basic Graph Patterns (BGPs) into
single SPARQL 1.1 queries of polynomial size. This task was simplified by the fact
that SPARQL does not support “non-distinguished” variables as used in CQs.
– We presented a schema-agnostic rewriting of general CQs in SPARQL 1.1, again
into single queries of polynomial size. This rewriting is more involved, and we used
two additional features: inline data (VALUES) and (in)equality checks in filters.
– We showed the limits of schema-agnostic rewriting in SPARQL 1.1 by proving that
many other OWL features cannot be supported in this way. This includes even the
most basic features of OWL EL and OWL RL, and mild extensions of OWL QL. It
also is not possible to rewrite regular path queries (and thus basic graph patterns of
SPARQL 1.1) into SPARQL 1.1, even for RDFS knowledge bases with assumption
of standard use. This would require a more expressive query language, such as
monadically defined queries [
Worst-case reasoning complexity remains the same in all cases, yet our approach is certainly more practical in the case of standard reasoning and BGP rewriting. For general CQs, the rewritten queries are usually too complex for today’s RDF databases to handle. Nevertheless, we think that our “SPARQL 1.1 implementation” of OWL QL query answering is a valuable contribution, since it reduces the problem of supporting OWL QL in an RDF database to the task of optimizing a single (type of) query. Since OWL QL subsumes RDFS, one can also apply our insights to implement query answering under RDFS ontologies, which again leads to much simpler queries.
The full details of our rewritings are beyond this abstract, as the length of the rewritten queries – polynomial or not – is too long to include full examples here. However, our basic approach to reasoning with SPARQL 1.1 can be motivated by some very simple 4 Nevertheless, it is also true that some RDF stores treat terminological triples in special ways, e.g., by keeping them in a dedicated named graph. observations. Consider a situation where our TBox is guaranteed to contain only axioms of the form A v B with A and B class names. Such axioms are encoded in RDF using triples of the form A rdfs:subClassOf B. Clearly, one can now query for all (inferred) instances of a class A using the graph pattern
f?X (rdf:type = rdfs:subClassOf ) Ag; which looks for elements ?X that are connected to class A through property rdf:type followed by zero or more uses of property rdfs:subClassOf. The queries used in our work are significantly more involved, since they need to take into account a much larger vocabulary used in OWL, including equivalent classes, subproperties and equivalent properties, inverses, n-ary class intersections, and existential restrictions. Moreover, the queries need to take into account the special semantics of > and the universal property, as well as the potential inconsistency caused by ? and the empty property.
An interesting observation here is that syntactic sugar can make schema-agnostic query rewriting more di cult. Clearly, taking into account many possible syntactic encodings must lead to larger queries, which will usually a ect execution times. However, the OWL feature owl:SymmetricProperty even makes query rewriting impossible altogether. This is surprising, since property symmetry can easily be expressed using inverses and subproperties, which are fully supported by our approach. Such e ects can occur since SPARQL 1.1 is not a universal computing formalism (for its complexity class). Note that these problems vanish if one allows even the most basic kinds of normalisation, but this is not always practical (e.g., when querying the DBpedia SPARQL endpoint).
An interesting side e ect of our work is that it provides a simple, worst-case optimal method for terminological reasoning in OWL QL (and thus DL-LiteR). As we treat TBox axioms as data, we can actually formulate queries over terminological knowledge, or even answer conjunctive queries where some class or property names are replaced by variables, with the intended meaning that these “meta-variables” range over vocabulary symbols of the ontology.5
Future steps in this line of research include empirical evaluations, where the main
challenge is to identify OWL QL benchmarks with non-trivial TBoxes. It should not
be assumed that the good theoretical properties of the approach translate directly into
good performance, and further optimisations and adjustments might be needed.
Implementation techniques such as partial materialisation would lead to a form of combined
rewriting (cf. [