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.
But that would make parallel processing needing communication for the
same reason that coordinating "same label means same bNode" needs
communication. [*]
Andy
[*] Actually, "same label - same bNode" does not need communication
depending on the implementation of internal ids.
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
>>
>>
>>
>