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
3. Queries
4. Examples
4-1. Employee and Department
4-2. Father and Person

Overview

DLV^E is a powerful extension of the well known DLV system for answering (unrestricted) conjunctive queries over strongly parsimonious programs, which is profitably applicable to ontology-based query answering.


Chapter 1. Getting Started

This is just a quick introduction to DLV^E and to the format accepted by the system. You can invoke DLV^E directly via command-line, as follows:

      
      ./dlvEx ONTOLOGY DATA [QUERY -cautious]

      ONTOLOGY: an ontology specification (list of files or a directory)
      DATA: a set of data (list of files or a directory)
      QUERY: a query over the input ontological theory (a single file)
    

Notice that, the QUERY parameter is optional, and option "-cautious" is mandatory only if there is a query in input. The input of the system (ontologies, data sets, and queries) should be compliant with the format that is described in the following section. If no queries are given in input, the system computes all atomic consequences of the ontological theory.

In the following lines, we suggest the input structure that can be adopted to speed up the evaluation.

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 of the ontology, starting from the query predicates. This information is used to filter out, at loading time, data belonging to predicates that are not relevant for the query at hand.

To this aim, we can distinguish between rule 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, the input query has to be expressed in a rule file with .rul extension. 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 the "p.data" file. [Importantly, the file must have the same name of the predicate]

If the input structure is compliant with the recommendations given above, the system first parses the rule files (ontology and query). Afterwards, it selects the subset of the ABox that has to be considered in order to answer the input query. In this case, the remaining part of the ABox is completely ignored by the parser. Note that, the above input structure is not mandatory. Any extension for input files can be used. However, if these suggestions are not considered the aforementioned optimization is not applied.

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

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

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

      ./dlvEx ./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 natively supports the Datalog^E language, that is the natural extension of plain Datalog that allows to express 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.

Note that if a variable X occurs in the head of a rule and it does not occur neither in the body nor in the #exists clause, then the rule is not safe.


Chapter 3. Queries

DLV^E has been devised with the aim of answering unrestricted first-order queries over strongly parsimonious programs. Hence, each query has to be expressed as a list of one or more literals, which must be separated by commata and terminated by a question mark. Notice that, existentially quantified variables have to be expressed according to the syntax introduced above.

Note: Only one query per time is considered. If you specify more than one query, only the last one (in order of appearence) is considered and an appropriate warning message is showed.

Example 3-1. Queries:

The following queries are compliant with the syntax of DLV^E.

      a(X) ?
      #exists{X,Y} a(X), b(X,Y), c(Y,Z) ?
      #exists{X} a(X,Y), b(Y,Z) ?

Chapter 4. Examples

What follows is a list of compact ontologies that are compliant with the syntax of 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, whereas 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")?