Re: Final text for Basic Graph Patterns

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.

	Andy

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