- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 02 Oct 2012 14:57:01 +0100
- 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 UTC