Re: RDF and OWL compatibility

Enrico Franconi wrote:
> 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.

Yes, but Datalog with negation under the common semantics (stable, wfs) 
can also cover negation and set difference, so I meant Datalofg with 
stratified negation, the recursive queries in SQL also only allow for 
the stratified use of negation, so also recursive views in SQL can be 
captured.

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

Thus, somewhat a conjunctive query?

> 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.

yes.

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

agreed.

> 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.

agreed.

> 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.

Thanks, will check these pointers!

axel
-- 
Dr. Axel Polleres
Digital Enterprise Research Institute - DERI Innsbruck
Institute of Computer Science, University of Innsbruck
+43-512-507/6486               Axel.Polleres@deri.org
http://www.polleres.net/

Received on Tuesday, 10 January 2006 08:16:50 UTC