W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2012

Re: agenda reminder for tomorrow...

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 02 Oct 2012 14:57:01 +0100
Message-ID: <506AF2AD.9050105@epimorphics.com>
To: public-rdf-dawg@w3.org


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
>>
>>
>>
>
Received on Tuesday, 2 October 2012 13:57:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:49 GMT