Re: RIF and QL

On 27 Jan 2006, at 11:26, Francois Bry wrote:
> Enrico Franconi wrote:
>
>> However, there may be several kinds of these 'connections': most  
>> of  them are based on a model-theoretic characterisation rather  
>> than on  entailment
>
> Entailment is defined in logic in model theoretic terms: F |= G  
> (formula
> F entails formula G) iff all models of F are models of G. Refering to
> this model theoretic definition, proof methds for entilment are  
> defined.

Sure, but entailment could also be defined in a non-model theoretic  
way (e.g., just proof theory like linear logic, or just  
algorithmically).

>> Let us restrict attention to the RDF and OWL ontology/knowledge-  
>> representation languages (we have at least to consider those two,  
>> as  per our charter). In order to super-simplify our life, let us  
>> in  addition restrict our attention to the case when those queries  
>> are  atomic: atomic binary predicates (a triple for RDF, a role  
>> for OWL)  and atomic unary predicates (a class in OWL).
>>
>> By adopting the 'trivial' semantics above, it is impossible to   
>> correctly capture correctly, for example, the function-free horn   
>> clause fragment of SWRL (which is, if you think a little about it,  
>> a  special case of the above but with FOL semantics);
>
> I do not understand why. Enrico, could you plewase give a clue to
> saimple-minded readers like me?

As I was point out one line below, the use cases in <http:// 
www.w3.org/2005/rules/wg/wiki/Managing_incomplete_information> can  
not be captured.

Take, for example, the case in <http://www.w3.org/2005/rules/wg/wiki/ 
Managing_incomplete_information#disjunctive-info>, which I rephrase  
below.

Given a KB with the only axiom:

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

and the fact:

   kb:customer("Paul").

and the rules:

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

we actually get, as expected, with either SWRL FOL semantics or  
Rosati's style LP semantics:

   cons:paying-customer("Paul").

But with the local evaluation of each body I don't get it.

The other examples <http://www.w3.org/2005/rules/wg/wiki/ 
Managing_incomplete_information> emphasise different aspects of this  
problem.

The moral? You can't be naïve when integrating rules with KBs.
This has to do with the fact that people with expertise in rules is  
"wired" into a vision of the world with complete information (the  
minimal model property is an aspect of it), while the example above  
shows that in the integration process we have to deal with incomplete  
information (hence the name of the use case).

--e.

Received on Friday, 27 January 2006 10:55:58 UTC