W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: Final text for Basic Graph Patterns

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sun, 15 Jan 2006 20:34:10 +0000
Message-ID: <43CAB1C2.8090209@hp.com>
To: Enrico Franconi <franconi@inf.unibz.it>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>

Enrico Franconi wrote:
> On 15 Jan 2006, at 19:01, Seaborne, Andy wrote:
>> Enrico Franconi wrote:
>>> The new proposal of Pat 
>>> <http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0061.html> 
>>> does not work for any approach where bnodes are implicit, and this 
>>> happens not only for OWL-Lite entailment, as we already pointed out 
>>> in 
>>> <http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0064.html>, 
>>> but also for RDF entailment. For example, given the graph
>>>     :john :age "25"^^xsd:decimal .
>>> the query
>>>     ASK { _:b rdf:type rdf:XMLLiteral }
>>> should clearly return YES if RDF entailment is considered.
>>> However,
>>> according to the latest proposal from Pat the answer to the query 
>>> would be NO regardless of the type of entailment considered. The 
>>> reason is that Pat considers bnodes in the query restricted to be 
>>> bound only to URIs and bnodes explicitly appearing in the graph.
>> This hinges on the different definitions of 'pattern solution'.  The 
>> scoping
>> graph proposal maps variables and bNodes; the ordered-merge proposal maps
>> just variables.  Each has consequences.
> The main consequence of Pat's latest proposal, as pointed out by FUB, is 
> that SPARQL can never be extended - not even to RDF entailment - as you 
> can see from the example above.
> Moreover, if you want to map both variables and bnodes, you better 
> disallow bnodes in the query and consider only variables in the query: 
> there wouldn't be any noticeable difference.

Wouldn't that disallow the extensions you are interested in such as 
OWL-disjunction?  With no bNodes, there would be no syntax for them :-) 
Seriously, to put them in the syntax so extensibility is possible, we need an 
account of them.

I'm trying to find a safe (and restrictive) thing to do now, and leave space 
for later work.

In SPARQL 2, we will have a service description which can say whether a query 
processor does things better/differently to SPARQL 1 (this version - simple 
entailment only but it can be over a derived graph.. Your rdfD1 example 
works).  This use of the service description gives a lot of room for 
extensibility in my opinion.  Different approach to extensibility, I guess.

>> If bNodes are bound by pattern solutions, then the algebra works out 
>> as per
>> the current document.
> And bnodes would behave *exactly* as variables, and therefore when 
> considering the extension of SPARQL with just RDF entailment, the 
> semantics would not be compatible, and the behaviour would be wrong.

Entailment-extensibility is possible on BGPs that do not share bNodes with 
other BGPs.

Otherwise they do behave as the variables do if a bNode occurs in two 
different BGPs in the same query.  That's the minimal change to the design. 
  We could ban them from spanning BGPs - that "flexes" the design more but if 
that is the way forward, then so be it.  I think it is true to the original WG 
decision on syntax from F2F/Boston.

I found the consequences on FILTER, and rewriting generally, quite surprising 
when there is no connection for bNodes of the same name across BGPs.

A later WG can work on reducing or removing this restriction if it can down. 
I happen to also think there will be a lot more features in SPARQL 2 so the 
interactions here will be more than we can conceive at this point in time. 
E.g. aggregation, subqueries, negation.


>> If bNodes are not bound at all, as in the ordered-merge proposal, then 
>> there
>> is a change to the algebra.
> Unless you forbid the use of bnodes in queries, which wouldn't be at all 
> a loss, since the behaviour you want for bnodes is the behaviour we have 
> for variables.
>> (...)
>> The algebra works if a bNode in occurring in two or more BGPs in a graph
>> pattern is bound by the pattern solution [*].
> Exactly: you expect bnodes to behave like variables, which is 
> semantically wrong for any type of entailment which is not just the 
> reading of the syntax (like simple entailment).
>> This is a conservative approach and, like any extension to the level of
>> entailment, more solutions might become possible when relaxed.  It 
>> would allow
>> all entailments for queries consisting of a single BGP.  It would 
>> leave open the possibility of the rdfD1 use case above as an extension.
> This is acceptable only if bnodes are forbidden in queries.
> cheers
> --e.
Received on Sunday, 15 January 2006 20:34:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC