Re: Final text for Basic Graph Patterns

Enrico Franconi wrote:
> 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.

Sorry - I fail to see why a restriction that a bNode can not appear in two 
separate BGPs is in anyway a conflict with anything you have said.  I 
suggested because it was the clearest way I could think of to give you the 
*exact* and *complete* behaviour you have been wanting.

The case I am considering is where the same bNode name is used in two 
different BGPs.  I can't find anywhere in your document or your emails as to 
what happens in this case so I worked an example.

The example has some consequences which might catch people out.  Furthermore, 
I don't see any value in having that situation - in your definitions it is 
equivalent to a syntactic rewrite to a new name anyway so I suggested that we 
use that (that is, don't allow

{ ... _:a ... }
   { ... _:a ... } union { ... }

where the name "_:a" is used twice.

instead have
{ ... _:a ... }
   { ... _:b ... } union { ... }

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

Plain RDF entailment is covered because then a bNode only occurs in a single 
BGP.  No constraints.

(Further, as there is no #owlDisjunction, the graph queried can be the 
calculated logical closure of the input anyway.)

	Andy

> 
> --e.
>

Received on Monday, 16 January 2006 10:20:12 UTC