Re: RDF and OWL compatibility

On 5 Jan 2006, at 16:51, Axel Polleres wrote:
> As we all know a large parts of SQL (except e.g. aggregates) can be  
> translated to Datalog, i.e. rules. (BTW: there are extensions of  
> rule languages by aggregates and also implemented systems for this  
> as well to capture even more of SQL).

Uh uh, this is a statement that may be misunderstood! Only select- 
project-join queries can be captured by datalog (the conjunctive  
queries); these are the SQL positive non-nested SELECT-FROM-WHERE  
queries. Complexity-wise there is a huge difference.

> So, wouldn't be the right way to go for us in terms of SPARQL  
> compatibility to similarly identify the kind of (deductive) rules  
> capturing SPARQL and identify where the limits of such a normative  
> translation of SPARQL queries into rules are which at first glance
> seems a quite straightforward way to go, but maybe I overlook some  
> major obstacles here, which I would be glad to hear from the fellow  
> WG members, especially those involved in the SPARQL WG!
>
> Having this normative translation we can treat SQARQL queries  
> nativley in the RIF rule language instead of the need to interface  
> with SPARQL.

OK, let's see the connection with SPARQL (I'm in the SPARQL WG,  
working on the semantics of SPARQL). First of all, to somehow  
parallel the notion of horn rules, we have to consider only the  
"basic graph pattern" queries, which in the body - surprise surprise  
- are just RDF graphs with in addition the possibility of having  
variables labelling nodes (in alternative to URIs and bnodes). A  
SPARQL basic graph pattern query returns a relation (the one  
identified by the variables in the body), *including* bnodes as  
values (not only URIs).

So, if you want to parallel this basic mechanism of SPARQL - which  
makes a lot of sense to me - you need to have a rule which allows for  
arbitrary triples in the body as atoms, whose terms may  be URIs -  
i.e., constants - bnodes - i.e., existential variables - and query  
variables - i.e., distinguished variables.  In the head you need a  
unique atom, whose term again may be URIs - i.e., constants - bnodes  
- i.e., existential variables - and query variables - i.e.,  
distinguished variables.

So, we notice that basic query patterns in SPARQL are absolutely  
equivalent to unsafe non-recursive function-free horn rules.

That's why I believe that the real problem here is again the unsafe  
existential variables in the head (i.e., the bnodes in the head) of  
the rule.

A major problem arises when you want to have recursive rules, which  
would actually enrich the expressivity of SPARQL, and - in a sense -  
it is one of the most important reasons to have rules in addition to  
plain SPARQL/RDF. Please look at the use case <http://www.w3.org/2005/ 
rules/wg/wiki/Managing_incomplete_information>, where two examples  
(in section "9.4. (Rules involving generation of unknown)") show how  
you can make things wrong with a naive use of skolem constants to  
implement the existential variables in the head.

cheers
--e.

Received on Monday, 9 January 2006 13:25:37 UTC