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

Re: agenda reminder for tomorrow...

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 2 Oct 2012 14:43:23 +0100
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <FAF0E2F9-4104-44D0-B263-CBD8BE9A58D4@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
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.

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 13:43:57 GMT

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