ObdalibQuestQuerylanguage - ConstantB/ontop-spatial GitHub Wiki

Table of Contents Query languages SPARQL Entailment regime Embedded queries Direct queries

Quest supports several query languages that we new detail. As with the ontology language and the rest of the features of Quest, we are constantly working to extend them. Changes and new features will be detailed here.

Also note that Quest takes into account the full ontology when answering queries, hence, the data that Quest uses to answer the queries is not only the given data, but also the implied data.

Last, in order to answer these queries, Quest does not expand the data or materializes inferences. Instead, Quest relies on query rewriting, i.e., all reasoning is done at query time. We work very hard to make the produced queries as efficient as possible.

Quest supports a restricted form of http://www.w3.org/TR/rdf-sparql-query/ SPARQL 1.0 queries which are evaluated using First-Order semantics. SPARQL queries are restricted to ABox queries, that is, queries about individuals and to other individuals and Literal values. ABox queries in Quest are restricted as follows, for each triple s p o in the query:

• p is never a variable.
• p is either rdf:type or a Property from the ontology.
• if p is rdf:type then o is a URI that refers to a Class of the ontology.
• if p is an URI that refers to a Property,

Moreover, the following restrictions apply to SPARQL queries in Quest:

• CONSTRUCT, DESCRIBE, OPTIONAL or FILTER are not allowed.
• SPARQL 1.1 features are not allowed, i.e., Aggregates, Subqueries, Negation, Expression in SELECT, Property paths, Assignments

We are working towards the extension of this query language. We expect each release to extend this language a bit further.

Note: Note that you using SPARQL syntax you can express UCQs, normal (using SELECT) and boolean (using ASK)

Examples of valid SPARQL queries:

PREFIX : <http://my.ontology/ontology1#>
SELECT * WHERE { ?p a :Person}

A SPARQL query asking for persons and their uncles.

PREFIX : <http://my.ontology/ontology1#>
SELECT ?p ?uncle WHERE { ?p a :Person. ?p :hasFather ?f. ?f :hasBrother ?uncle}

The same query as above but with SPARQL shortcuts.

PREFIX : <http://my.ontology/ontology1#>
SELECT ?p ?uncle WHERE { ?p a :Person; :hasFather [ :hasBrother ?uncle] }

Some examples of invalid queries:

PREFIX : <http://my.ontology/ontology1#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?class WHERE { ?class rdfs:subClassOf :Person }

PREFIX : <http://my.ontology/ontology1#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?class WHERE { :john a ?class }

PREFIX : <http://my.ontology/ontology1#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?class ?predicate WHERE { ?class ?predicate :Person }

Quest uses DL-Lite entailments to answer SPARQL queries. This entailments are similar to the OWL 2 QL entailment regime, however it differs in some aspects that we will detail here.

Here we explain the differences in semantics of SPARQL 1.1 entailment regimes (particularly OWL 2 QL) and the entailment regime we use in Quest. For example

• We may derive existential constants (blank nodes) and use them to answer queries, in SPARQL over RDF this is not possible.

A powerful feature of Quest is the support for embedded queries, i.e., general SQL queries that use embedded SPARQL or UCQ queries as source for their data in the FROM clause of the SQL query. The SQL is not restricted, and any SQL constructs allowed by the RDBMS that you use are supported. The embedded SPARQL or UCQ queries are restricted as described in the previous sections.

An embedded query is given with the following syntax:

{| border=1 class="simple"
! ($SPARQL/ $UCQ) 
! ')' $NAME
|}

Where $SPARQL and $UCQ are SPARQL and UCQ queries respectively and $NAME is a string that can be used as a reference for the results of the SPARQL or UCQ query. Variables outside of the embedded table must be references using $NAME.VARIABLENAME. For example, the following is a valid embedded query:

SELECT view1.x, view1.project FROM etable ( 
    PREFIX : <http://ontology.org/example#>
    SELECT ?x ?project ?salary 
         WHERE { ?x a :Employee; 
                      :works-for ?project;
                      :has-salary ?salary .
          }
) view1 WHERE view1.salary > 27436

Note that etable can be used several times in the query, as well as real tables from the database schema. Using embedded tables you can express negation and use the full power of SQL over the results of ontological queries.

One extra candy in Quest w.r.t. queries is the ability to query the database directly. You can do this simply by prefixing your query with the text: /*direct*/ this will tell Quest that the rest of the text is a query that should be evaluated by the database. For example:

/*direct*/
SELECT * FROM concept

Direct queries are useful for debugging. Also, if you are curious about the in-memory databases created by Quest you can inspect them using direct queries.