[Use Case] FUB-1 Managing incomplete information

MANAGING INCOMPLETE INFORMATION
-------------------------------

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",
"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"),
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.

***[use case (a): existential information]:

"Is Paul a customer with an address?"

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

In a framework with a 'classical' semantics we actually get
db: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
db:customer-with-address("Paul")
since variables (including the 'Y') are grounded on the herbrand
universe.

***[use case (b): disjunctive information]:

"Is Paul a paying customer?"

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

In a framework with a 'classical' semantics we actually get
db: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
db:customer-with-address("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).

***[use case (c): multiple model information]:

[this is the (in)famous Little House example from
  <http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0069>]

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

db:query(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
db:query("Paul")
as expected, since Andrea pays either cash or with a credit card, so
that Paul is in any model in the extension of db:query.

However, in most approaches integrating rules with ontologies it is not
true that
db:query("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).

IMPLICATIONS
------------

- 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

- RDF(S) and DLP do not introduce incomplete information, since they
   have the minimal model property

- 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

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