8 Wait for DIG 2.0 – or use DIG 1.2 now

In many practical application systems based on DLs, a powerful ABox query language is one of main requirements. Conjunctive queries and unions of conjunctive queries are topics of recent research in this context. Additionally, query languages for so-called grounded conjunctive queries and some other practically motivated constructs have been used in existing DL systems for a long time. In this section, an ABox query language as part of the DIG protocol is introduced as part of an extension to DIG 1.1 (called DIG 1.2). The query language will be part of the upcoming DIG 2.0 standard with slight modifications (mostly, tags will be renamed to match up with other parts of DIG 2.0). For now, conjunctive queries are offered as part of RacerPro DIG 1.2.

8.1 Identification response

The response to an <identifier/> request includes a new element <retrieve> within the <ask> tag. Additionally, the tag lang can be specified to identify the fragment of a query language supported by the reasoner. Possible values are e.g. cq (conjunctive queries), ucq (unions of conjunctive queries), focq (first order conjunctive queries), ugcq (unions of grounded conjunctive queries) and so on. An example for a reasoner identification:

8.2 Ask language

A query consists of a query head and a query body. Moreover, variables and individuals can be used in queries.

An asks part now can contains the new ask statement retrieve which has an attribute id as unique identification of the query and for which a query head (tag head) and a query body (tag body) must be defined. Within the head tag Abox individuals and variables (denoted as indvar) can be used. Variables are bound to those individuals which satisfy the query. For boolean queries, the head must be empty. The query body is built from query atoms (see below) using boolean constructs qand, qunion, and qneg, respectively. Query atoms can be concept query atoms or role query atoms, denoted with cqatom and rqatom, respectively. Concept query atoms consist of variables (or individuals) and complex concept expressions. Role query atoms consists of at least two identifiers for variables (or indidivuals) followed by a role expression.

The following conjunctive query with id=q1 asks for all individuals of the concept woman which have female children. The requested knowledge base is identified by means of a URI:

The following query q2 consists of conjunction of a concept query atom and a role query atom. It returns all mother-child pairs (bound to variables x and y):

The following boolean query q3 asks if there are any individuals of the concept woman in the current ABox:

Instead of variables, also ABox individuals can be used in the query, as illustrated by example of the following (boolean) query q4:

As mentioned above, within the retrieve statement we can build unions of conjunctive queries using the operator qunion in front of the conjunctive queries:

The qneg operator can be used in front of query body atoms, conjunctive queries and unions of conjunctive queries. For the semantics, see below.

A qsameas query atom can be used to enforce a binding of a variable (e.g., <indvar name="betty"/>) to an individual (e.g., <individual name="betty"/>), or to enforce that two non-injective variables are bound to the same individual.

Instead of qsameas one may use qdifferent to search some human that does not love himself.

Sometimes an explicit projection operator in the query body is required in order to reduce the ”dimensionality” of a tuple set when the query answer is computing. For DIG we propose a tag project which can be used in any position within a query body and contains a head and a body parts. The following query returns all mothers which do not have a known (i.e. explicitly modeled in an ABox) child:

When a reasoner has to deal with large ABoxes, iterative query answering can help to improve the performance of query answering. To support the incremental loading the answer tuple by tuple, the statement retrieve can have an additional attribute ntuples instantiated with the maximum number of tuples which are assumed to be returned. If ntuples is not specified, all tuples have to be returned.

The statement retrieve without head and body is used to retrieve the next tuple(s) for a particular query identified with qid. The value of qid can be a query id or an answer set id (asid):.

8.3 Tell language

In order to tell the reasoner that no more tuples will be requested, we propose the tag releaseQuery.

8.4 Response syntax

The response to a retrieval request have an attribute id which corresponds with the id of the submitted query. The answer set id (asid) will be generated by the reasoner. The response contains tuples of bindings for variables mentioned in the query head. The response head is the same as the head of the corresponding query. The variable bindings follow the bindings tag. The head is inserted just for convenience; the reasoner may not reorder components of tuples. For example, the following answer is returned for the query with the id q2 posed above:

The response to a boolean query is a binding list with an empty tuple for true or an empty binding list for false.

Within the bindings statement, the tag notifier can be used for reasoner-specific messages. E.g., considering an incremental query answering, the reasoner can report that the given tuple is the last one:

Other messages are possible. For instance, a reasoner could indicate that subsequent requests for tuple will require considerably more resources. Motivated by this example, a reasoner might decide to return fewer tuples than requested with the attribute ntuples (see above).

8.5 Taxonomy queries

If only slight modifications are made to a taxonomy, for instance, if only a single axiom is added, applications that need access to the taxonomy have to retrieve the whole taxonomy using single queries in DIG 1.1. In DIG 1.2 there are two new queries defined: one for the retrieval of the whole taxonomy, and another for the incremental retrieval of the taxonomy (i.e., only the parts that have changed are indicated). We illustrate the facilities using an example. Let us assume that in the default Tbox, there is the following axiom.

The following DIG 1.2 message is sent to RacerPro (uri="" indicates a reference to the default Tbox of RacerPro).

The result is the following.

Next, two axioms

are added, and the following DIG 1.2 message is sent to RacerPro.

The answer returned by RacerPro is:

If there are very few changed in a large ontology, the incrementalTaxonomy query reduces communication overhead. Instead of incrementalTaxonomy there is also a query taxonomy which produces the result of the first incrementalTaxonomy.³

RacerPro does not delete a knowledge base corresponding to a releaseKB. The statement releaseKB is sent by tools at the end of the interaction. Many users, however, would like to inspect the KB with RacerPorter afterwards. Thus releaseKB keeps the KB on the server. Use deleteKB. instead if you generate you own knowledge bases using DIG.