Re: Final text for Basic Graph Patterns

On 15 Jan 2006, at 21:34, Seaborne, Andy wrote:
>> 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.

But if you want a enxtension which is backward compatible, you need  
to have the proper semantics for them. If your community does not  
accept the proper semantics, I propose to leave them out exactly for  
the sake of exensibility.

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

So do I.

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

I guess. If SPARQL2 can not have backward compatibility *by  
definition* that is a failure, and the user's community is not going  
to like that.

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

No. Because the semantics of bnodes would be different and not  
extensible anyway. See our example on RDF entailment: one bnode, one  
BGP, as simple as that.

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

You decide what you want, I just warn that it will not scale up.

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

The problem of SPARQL2 will appear just when considering plain  
positive RDF entailment - again, see our example.

--e.

Received on Sunday, 15 January 2006 22:58:15 UTC