W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2006

Re: RDF and OWL compatibility

From: Axel Polleres <axel.polleres@uibk.ac.at>
Date: Tue, 10 Jan 2006 09:13:12 +0100
Message-ID: <43C36C98.7050202@uibk.ac.at>
To: Enrico Franconi <franconi@inf.unibz.it>
CC: axel.polleres@deri.org, Dave Reynolds <der@hplb.hpl.hp.com>, Michael Sintek <sintek@dfki.uni-kl.de>, public-rif-wg@w3.org

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 

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


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

Thanks, will check these pointers!

Dr. Axel Polleres
Digital Enterprise Research Institute - DERI Innsbruck
Institute of Computer Science, University of Innsbruck
+43-512-507/6486               Axel.Polleres@deri.org
Received on Tuesday, 10 January 2006 08:16:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:36 UTC