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


From: Enrico Franconi <franconi@inf.unibz.it>
Date: Fri, 27 Jan 2006 12:33:26 +0100
Message-Id: <992C1ABE-BE39-447A-8225-97E2AB1EA709@inf.unibz.it>
To: W3C RIF WG <public-rif-wg@w3.org>

I'm sorry I wasn't at the latest telcon.

 From the minutes:

> Christian de Sainte Marie: SPARQL query as body would be a good  
> compatibility with RDF. Why not the same approach on the conclusion  
> side? If we use query languages as a mean to ensure compatibilty on  
> the query side, why not also on the conclusion side?
> Edward Barkmeyer: my concern is that interpreting RDF like SPARQL  
> does.
> Jos De Bruijn: SPARQL does not adhere to RDF semantics

SPARQL conforms completely to RDF MT semantics as in the published  
specs of RDF.
The newest version of the SPARQL semantics <http://www.w3.org/2001/sw/ 
DataAccess/rq23/#BasicGraphPatternMatching> is parametric wrt various  
types of entailments, including RDF and OWL entailments.

> Edward Barkmeyer: conclusions in rule heads might not be compatible  
> with RDF model.

What do you mean here?

> Axel Polleres: hmmm, if we allow SPARQL (or any other query  
> language) in the body and the query is recursively dependent on the  
> rule consequent... we are gonna run into some issues

If we restrict the use of SPARQL to the core Basic Graph Patterns  
(BGPs, i.e., a conjunction of triples with URIs, bnodes,  
distinguished variables) then RIF could easily *extend* this core  
SPARQL with recursion. We could choose a SWRL (i.e., FOL) style  
semantics, or a Rosati's LP semantics for it, but in both cases this  
would be well defined.

> Edward Barkmeyer: merging RDF facts with rule engine facts will  
> yield interesting quertions on what the interpretation migft be.

I believe that if we work all together around a table for few hours,  
a characterisation of the different options can be easily found.

> Jos De Bruijn: being member of SPARQL WG: SPARQL query is noly  
> filter. Therefore can be used in rule bodies. We do not see any  
> issue at all if looking at SPARQL as filter rule.

If I understand well, this wouldn't be different in practice from  
Francois' proposal of 'procedural attachment'.

> Chris Welty: How to handle, meaning of query language in  
> consequences unclear.

In a very general sense, a (atomic) query is an (atomic) open  
formula, so it makes sense also in the head of a rule (the free  
variables of the formula being the distinguished variables). The  
problem happens if the (atomic) query contains an existential  
variable (e.g., a bnode), since this would make the rule unsafe.

> Chris Welty: Bnode semantics?
> Jos De Bruijn: we cannot resolve it yet

There is a problem only if we allow a RDF triple in the head of a  
rule, and a bnode appears in it: this would be an unsafe rule.

> Chris Welty: Email exhange look like it has come to a resolution.  
> Anyone to write down on that?

> Michael Kifer: We cannot make any clear decision wrt semantics. We  
> can write down in rthe wik what the issues/problems are.

I understand that we may end up with a clear understanding of the  
different options in the semantics, if we just spend few hours  
together with MKifer.

> Michale will write in wiki issues related to bnode semantics.

OK, I'll wait for it. I can help somehow.

> Jos De Brujin will update wiki page on bnode semantics.

OK, I'll wait for it. I can help somehow.

> Jos De Brujin: Comment on SPARQL: seems to also disregard bnodes.


> Chris Welty: Volunteer to write about bnode/SPARQL?
> Jos De Roo: will report on what is going on in SPARQL concerning  
> bnodes.
> Chrisitan de Sainte Marie: Enrico is also in SPARQL WG and copuld/ 
> should also report on node issue.

yeah, that's me.
I don't understand what you want to know.
Let me restrict to the above defined core SPARQL (with only BGPs -  
this is legitimate, since the rest of SPARQL is just an SQL  
compatible algebra on top of BGPs).

Very informally speaking, an answer to a core SPARQL query is an  
assignment of the variables to URIs *or* bnodes that makes the query  
with that assignment entailed by the original RDF data. The bnodes in  
the query play the role of existential (i.e., non distinguished)  
variables; the bnodes in the answer also play the role of existential  

> Jos De Bruijn: ACTION: JosB create a wiki page explaining the issue  
> with bNode semantics and summarize the possible solutions which  
> have come up during the discussions on the mailing list [recorded  
> in http://www.w3.org/2006/01/24-rif-minutes.html#action12]

OK, I'll wait for it. I can help somehow.

Received on Friday, 27 January 2006 11:33:45 UTC

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