Re: agenda reminder for tomorrow...

On 2012-10-02, at 14:57, Andy Seaborne wrote:
> 
> On 02/10/12 14:43, Steve Harris wrote:
>> I would prefer that 3/ have two bNodes, having the label scope cross ;s strikes me as a bit strange (just visually/aesthetically).
>> 
>> It would be nice to be able to dispatch INSERT DATA … ; INSERT DATA … in parallel, though this is not a particularly strong use-case.
> 
> The other option is to ban use of the same label in different operations (carefully - DATA only).  I have not checked the effect on the test suite.

An other option? If bNode labels scope is stopped by ; (as in INSERT … WHERE) then there's no co-ordination needed.

> But that would make parallel processing needing communication for the same reason that coordinating "same label means same bNode" needs communication. [*]

It can be (pre-)parsed in one location, the operations can be carried out distributed. We do this with Keepalive PUTs, but not Updates currently.

We have to pre-parse in any case to ensure that the operations are orthogonal, e.g. all INSERT DATA {} (or theoretically INSERT WHEREs that can't have cross-effect each other).

> 	Andy
> 
> [*] Actually, "same label - same bNode" does not need communication depending on the implementation of internal ids.

Yes.

- Steve

> Error detection in parallel parsing does regardless.
> 
>> 
>> I believe we sometimes glob small updates like this, and it would require us to be careful with bNode labelling in that case.
>> 
>> I also find Olivier's argument about 3/ and 4/ being equivalent to be pretty persuasive.
>> 
>> On the other hand PREFIXes span multiple ; blocks (to some extent), so there's a bit of precedent. That decision hasn't been wildly popular though.
>> 
>> I wouldn't object to either decision, though I might reserve "told you so" rights til the next WG :-)
>> 
>> - Steve
>> 
>> On 2012-10-02, at 11:22, Andy Seaborne wrote:
>> 
>>>> Concerning insert-data-same-bnode2.ru I prefer that the scope of  bnode
>>>> _:b be one insert data  and hence that the generated bnodes be different.
>>>> The reason is that if you execute the two insert data using one query or
>>>> using two queries, the result is the same. Also it is more uniform with
>>>> insert where.
>>> 
>>> GRAPH is not a factor so let's simplify a bit:
>>> 
>>> Consider
>>> 
>>> 1/
>>> One operation
>>> Two uses of a bNode label in one INSERT DATA
>>> 
>>> INSERT DATA { _:b :p :o1 .
>>>              _:b :p :o2 . }
>>> 
>>> 2/
>>> One operation
>>> Only one syntactic mention of of _:b
>>> 
>>> INSERT DATA { _:b :p :o1 ; :p :o2 . }
>>> 
>>> 3/ Two operations, one request
>>> INSERT DATA { _:b :p :o1 } ;
>>> INSERT DATA { _:b :p :o2 }
>>> 
>>> 4/ Two operations, two requests
>>> 
>>> Request 1:
>>> INSERT DATA { _:b :p :o1 }
>>> 
>>> Request 2:
>>> INSERT DATA { _:b :p :o2 }
>>> 
>>> 
>>> Cases (1) and (2) have the same bNode and because of (2) they must be the same bNode.  And it's that way in Turtle and SPARQL 1.0.
>>> 
>>> Cases (1) and (4) must be different.
>>> 
>>> We are left where the change happens - is (3) like (4) or (1)/(2)?
>>> 
>>> We already distinguish requests as atomic ("SHOULD be").  So across two requests, other things can change.  Requests are also the unit in the protocol and in the grammar.
>>> 
>>> I see (3) as just a different syntax, like (2) is to (1) hence I prefer (3) to be be like (1).  The rule is labels are scoped to the document (which is the request) rather than make an "operation" a significant unit.
>>> 
>>> This is not a "must be" technical decision - it's about style.
>>> 
>>> It also means ";" works like concatenating Turtle files in regards to label scoping.
>>> 
>>> 	Andy
>>> 
>>> 
>>> 
>> 
> 

-- 
Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
80 Victoria Street, London, SW1E 5JL

Received on Tuesday, 2 October 2012 14:13:17 UTC