DLV^E - User Manual

Nicola Leone

Marco Manna

Giorgio Terracina

Pierfrancesco Veltri


Table of Contents
Overview
1. Getting Started
2. The Language of DLV^E: Datalog^E
3. Queries
4. Examples
4-1. Employee and Department
4-2. Father and Person

Overview

DLV^E is a powerful system, based on the well known DLV system, for answering conjunctive queries over Shy programs, which is profitably applicable to ontology-based query answering. To the best of our knowledge, DLV^E is the first system supporting the standard first-order semantics for unrestricted CQs with existential variables over ontologies with advanced properties (some of these beyond AC_0), such as, role transitivity, role hierarchy, role inverse, and concept products.


Chapter 1. Getting Started

This is just a quick introduction to Datalog^E and DLV^E. You can invoke DLV^E directly on the command-line, as follows:

      
      ./dle ONTOLOGY [QUERY -cautious]

      ONTOLOGY: an ontology specification (list of files or directory)
      QUERY: a query over the input ontology
    

If there is a query in input the option "-cautious" has to be used. The ontology (TBox, ABox and, eventually, the query) have to be expressed in Datalog^E format. If you give no queries in input but only an ABox and a TBox, the system will compute all atomic consequences of the program.

In the following some suggestions on the input structure that can be adopted.

Since DLV^E is an in-memory system, it needs to load input data in memory before the reasoning process can start. In order to optimize the execution, the system first singles out the set of predicates which are needed to answer the input query, by recursively traversing top-down (head-to-body) the rules in P, starting from the query predicates. This information is used to filter out, at loading time, the facts belonging to predicates irrelevant for answering the input query.

To this aim, we can distinguish between rules files (TBox) and data files (ABox). The extension ".rul" can be used for TBox's files, and ".data" for ABox's ones. Note that, obviously, an eventual query in input has to be expressed in a rule file. The input ABox can be structured as follows: it can be used a file, "p.data", for each predicate name "p" of the ontology. Thus, all and only the assertions regarding "p" will be stored in it. Note that the file has to be named with the same name of the predicate.

If this input structure is used the program first scan the rules files and then (by considering the input query and the TBox) it select a subset of the ABox that have to be considered in order to answer the input query. In this case the other part of the ABox is totally ignored by dlv parser. Note that this input structure is not mandatory. It can be used any other extension for input files, the program will accept it. But, if the previous suggestions are not followed the optimization on the parsing task will not be applied.

The option "-stats++" can be used in order to analyze system performances.
In the following some examples of use:

      
      ./dle ./father_person.rul ./person.data -cautious -stats++

      ./dle ./employee_dep.rul ./employee.data -cautious -stats++

      ./dle ./univ-bench.rul ./query1.rul ./5/* -cautious -stats++
    

For any questions, bugs, errors, bad performance, etc. please contact us at veltri@mat.unical.it


Chapter 2. The Language of DLV^E: Datalog^E

DLV^E's native language is Datalog^E , the natural extension of plain Datalog that allows existentially quantified variables in rule heads. For example:

      
      #exists{Y,Z} p(X,Y,Z) :- r(X), t(X).

This rule states that for each X that is in both r and t, there should be two individuals (Y and Z) such that p(X,Y,Z) holds.

      
      s(X,Y) :- p(X,Y,_).

This is a plain Datalog rule, projecting the first two parameteres of p into s.

    
      #exists{Z} q(X,Z) :- s(X,_), t(X).

This rule states that for each X that is in both t and s at first position, there should be an individual, Y, such that q(X,Z) holds.

Note that if a variable X appears in the head of the rule but neither in the body nor in the #exists clause, the rule is not safe.


Chapter 3. Queries

In general, by posing a query one looks for ground substitutions such that the substitution applied to the query is true or validated by the rest of the program.

Queries consist of one or more literals, which must be separated by commata and terminated by a question mark. Note that if you want to express some existentially quantified variables in the query you have to follow the syntax seen above for program rules. Only one query per program is considered.

Note: If you specify more than one query, only the last one will be considered and DLV will issue an appropriate message.

Example 3-1. Queries:

The following three are ground queries,

      a ?
      b, c ?
      a2(h,i,j,k), b1(1,2,3) ?

while the next three are non-ground queries.

      a(X) ?
      #exists{X,Y} a(X), b(X,Y), c(Y,Z) ?
      #exists{X} a2(Z,i,X,k), b1(X,Z,3) ?

Chapter 4. Examples

What follows is a list of example programs executable by DLV^E.


4-1. Employee and Department

Consider an employee database, which stores information about managers, employees, and departments, where managers may supervise employees and direct departments, and employees may work in a department. The relational schema R consists of the unary predicates manager and employee as well as the binary predicates directs, supervises, and works_in with obvious semantics. In this context:

  • every manager is an employee:
     employee(M) :- manager(M).
    
  • every manager directs at least one department:
     #exists{P} directs(M,P) :- manager(M).
    
  • every employee supervising a manager is a manager:
     manager(E) :- employee(E), supervises(E,E'), manager(E').
    
  • every employee who directs a department is a manager, and supervises at least another employee who works in the same department:
     #exists{E'} aux(E,E',P) :- employee(E), directs(E,P).
     manager(E) :- aux(E,E',P).
     supervises(E,E') :- aux(E,E',P).
     works_in(E',P) :- aux(E,E',P).
    

4-2. Father and Person

Consider a family database, which stores information about fathers and persons, where every person must have a father, which has to be a person as well. In this context:

  • every person has a father:
     #exists{X} father(X,Y) :- person(Y).
    
  • every father has to be a person as well:
     person(X) :- father(X,Y).
    
  • the individual "pierfrancesco" is a person:
     person("pierfrancesco").
    

In the following we have a query over this program: who is the grandfather of "pierfrancesco"?

 #exists{Y} father(X,Y), father(Y,"pierfrancesco")?