• Managing incomplete information

This is one of the possible Use Cases.

1. Abstract

In applications which use information systems mediated by rules with ontologies, deduction about the incomplete parts of the information base may be non trivial. This use case introduces possibly the simplest examples of the impact of incomplete information (such as the one introduced by simple ontologies) in a rule framework integrated with ontologies.

2. Status

• Originally proposed by: EnricoFranconi (FUB)

• This use case has an impact on any application based on an information system (e.g., a database, an rdf data store, a persistent data storage) whose access is mediated by a rule based system with an ontology.

• We have prototypical implementations in the Sewasie system (see the "online demo") and the BBQ system; a complete scalable and robust re-engineering is underway under the name Asado.

3. Links to Related Use Cases

4. Relationship to OWL/RDF Compatibility

In this use case the ability of the rule system to be coupled with an ontology is crucial; this could be any of the following:

• RDF
• RDFS
• OWL-Lite
• OWL-DL

5. Examples of Rule Platforms Supporting this Use Case

• As far as we know, no commercial rule platform supports this use case.

6. Benefits of Interchange

• This use case emphasises the importance to have a clear semantics of the use of rules together with ontologies when used to access information systems: in fact, different meanings of the rules may lead to different answers by the system after the interchange.
• Interoperability between rule based systems will be enhanced, since their run-time behaviour will be unambiguously understood.

7. Requirements on the RIF

• A clear definition of the semantics of the rules to be interchanged.

• We do not propose to stick to a unique semantics, but we propose to clarify and formalise all the different semantics that may be of interest to users and implementors.

8. Breakdown

8.1. Actors and their Goals

• Information Provider - a business using an information system mediated by rules with ontologies

• Ontology Designer - designs the information system mediated by rules with ontologies

• Information Consumer - wants to get the answer to an information need expressed by rules

8.2. Main Sequence

• An Information Provider (a travel agency in our use case) has an information system storing (incomplete) data about its customers.
• A knowledge base states general information about the domain; the knowledge base is designed by the Ontology Designer on top of the database system.

• An Information Consumer (e.g., a larger application accessing the core rule based system via an API, or the travel agent mediated by a query building GUI, such as ''SQoogle'') queries the system for some information.

8.3. Alternate Sequences

1. Rules involving existential information

2. Rules involving disjunctive information

3. Rules involving multiple model information

4. Rules involving generation of unknown

9. Narratives

A travel agency has an information system storing (incomplete) data about its customers. A knowledge base states general information about the domain:

"travellers have an home address",

"travellers either pay cash or pay with a credit card";

• Class(kb:traveller partial restriction(kb:homeAddress someValuesFrom (owl:Thing))).

  Class(kb:traveller partial unionOf(kb:paysCash kb:paysCC)).

Note that the statements in the above knowledge base can not be expressed neither in RDF(S) nor in DLP; both can be expressed in OWL-Lite, and the first one can be expressed in DL-Lite. The above statements could be expressed equivalently as follows:

• kb:traveller rdfs:subClassOf (some kb:homeAddress owl:Thing).

  kb:traveller rdfs:subClassOf unionOf(kb:paysCash kb:paysCC).

The (ground) data includes:

"Paul, Andrea, Simon, Caroline are customers",

"Paul and Andrea are travellers",

"George and Ringo are employees",

"Simon pays with credit card",

"Caroline pays cash",

"Paul travels with Andrea and Simon",

"Simon travels with Andrea",

"Andrea travels with Caroline";

• db:customer("Paul"), db:customer("Andrea"),

  db:customer("Simon"), db:customer("Caroline"),

  kb:traveller("Paul"), kb:traveller("Andrea"),

  db:employee("Paul"), db:employee("Andrea"),

  kb:paysCC("Simon"), kb:paysCash("Caroline"),

  db:travels-with("Paul","Andrea"), db:travels-with("Paul","Simon"),

  db:travels-with("Simon","Andrea"), db:travels-with("Andrea","Caroline").

An application on top of the information system uses rules to derive new information.

9.1. (Rules involving existential information)

The Information Consumer asks for the query:

"Is Paul a customer with an address?"

expressed using the following rule:

• cons:customer-with-address(X) :- db:customer(X), kb:homeAddress(X,Y).

In a framework with a classical semantics we actually get

• cons:customer-with-address("Paul")

as expected, since Paul is a customer and a traveller, and travellers do have an address by definition in the knowledge base.

However, in most approaches integrating rules with ontologies it is not true that

• cons:customer-with-address("Paul")

since variables (including the Y) are grounded on the herbrand universe.

9.2. (Rules involving disjunctive information)

The Information Consumer asks for the query:

"Is Paul a paying customer?"

expressed using the following rules:

• cons:paying-customer(X) :- db:customer(X), kb:paysCC(X).

  cons:paying-customer(X) :- db:customer(X), kb:paysCash(X).

In a framework with a classical semantics we actually get

• cons:paying-customer("Paul")

as expected, since Paul is a customer and a traveller, and travellers - by definition in the knowledge base - do pay either cash or with a credit card so that at least one of the two rules is fired for Paul.

However, in most approaches integrating rules with ontologies it is not true that

• cons:paying-customer("Paul")

since rules operate on a preferred (minimal) model, which in this case assumes that Paul is neither paying cash nor with credit card (being neither of the two facts provable individually).

9.3. (Rules involving multiple model information)

This is the (in)famous DAWG Little House use case from http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0069.

The Information Consumer asks for the query:

"Is Paul a customer travelling with somebody paying with credit card who's travelling with somebody paying cash?"

expressed using the following rule:

• cons:complex-traveller(X) :- db:customer(X),

  • db:travels-with(X,Y), kb:paysCC(Y),

    db:travels-with(Y,Z), kb:paysCash(Z).

In a framework with a classical semantics we actually get

• cons:complex-traveller("Paul")

as expected, since Andrea pays either cash or with a credit card, so that Paul is in any model in the extension of cons:complex-traveller.

However, in most approaches integrating rules with ontologies it is not true that

• cons:complex-traveller("Paul")

since rules operate on a preferred (minimal) model, which in this case assumes that Andrea is neither paying cash nor with credit card (being neither of the two facts provable individually).

9.4. (Rules involving generation of unknown)

In this part of the use case we assume that part of the knowledge is not expressed by means of ontology statements, but by means of additional rules, given that both George and Ringo are known to be employees:

• db:employee(X) :- kb:works-with(X,Y).

  kb:works-with(Z,X) :- db:employee(X).

Please note that the above rules are normally expressible in a rule system that interoperates with RDF knowledge bases. In fact, it is enough to replace db:employee(X) with rdf:type(X,db:employee) in order to get a rule system where each atom is an RDF triple:

• rdf:type(X,db:employee) :- kb:works-with(X,Y).

  kb:works-with(Z,X) :- rdf:type(X,db:employee).

9.4.1. Infinite chain

The Information Consumer asks for the query:

"Is it true that George works with somebody that works for somebody that works for somebody who is an employee?"

expressed using the following rule:

• cons:group-worker(X0) :- kb:works-with(Z0,X0), kb:works-with(Z1,Z0), kb:works-with(Z2,Z1), db:employee(Z2).

In a framework with a classical semantics we actually get

• cons:group-worker("George")

as expected, since the rules would fire for an arbitrary long chain of db:works-with relations, being the rules mutually recursive and having an existential variable in the head of the second rule; this exemplifies what in database theory is called infinite chase.

However, in most approaches handling rules it is not true that

• cons:group-worker("George")

since an improper use of skolem constants in the head of the second rule prevents that.

9.4.2. False coreference

The Information Consumer asks for the query:

"Is it true that George and Ringo work with the same person?"

expressed using the following rule:

• cons:same-coworker(X0,X1) :- kb:works-with(Z0,X0), kb:works-with(Z0,X1)

In a framework with a classical semantics we do not get

• cons:same-coworker("George","Ringo")

since clearly we are not sure that the co-worker of George is the same as the co-worker of Ringo.

However, in most approaches handling rules it is true that

• cons:same-coworker("George","Ringo")

since an improper use of skolem constants in the head of the second rule forces that.

9.4.3. Missed coreference

Given the following rules:

• cons:employed-by(X,Y) :- db:employee(X).

  cons:company-location(Y,Z) :- cons:employed-by(X,Y).

  cons:company-name(Y,Z) :- cons:employed-by(X,Y).

The Information Consumer asks for the query:

"Is it true that there is a company with a name and a location?"

expressed using the following (boolean) rule:

• cons:company-prop() :- cons:company-location(X,Y), cons:company-location(X,Z).

In a framework with a classical semantics we do get a positive answer to the above rule.

However, in some approaches handling rules the above rule would have a negative answer, due to an improper use of skolem constants as null values.

10. Commentary

1. The above use cases are among the simplest examples of the impact of incomplete information (such as the one introduced by simple ontologies) in a rule framework integrated with ontologies (for example, either OWL-Lite or RDF).
2. A trivial ontology language such as DLP does not introduce incomplete information, since it has the minimal model property.
3. It is important to devise a (or several alternative) precise and formal semantics to the rule framework, so that these use cases will have a non-ambiguous meaning.

4. Ideally, when expressible, it is desirable to get the expected intuitive behaviour called classical semantics in the use cases above.