W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: Comments on SPARQL 1.1 Update (4)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 03 Sep 2010 13:27:00 +0100
Message-ID: <4C80E994.70809@epimorphics.com>
To: Steve Harris <steve.harris@garlik.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>


On 03/09/10 12:02, Steve Harris wrote:
> On 2010-09-03, at 11:30, Andy Seaborne wrote:
>
>> This comment is about the design of the update language syntax, not the document itself.
>>
>> In Turtle and N-triples, simple concatenation of files (except for implicit base IRI in Turtle and local bNode naming) results in a single, combined data file that is legal Turtle / N-Triples.  The thing in Turtle that makes this possible is that @prefix and @base can appear anywhere between triple specifications and defines prefixes or base IRI from that point on in the file.  This isn't a widely used feature as far as I know but it's useful at times.
>>
>> SPARQL Update does not have this property.  Currently, the prologue of BASE and PREFIX must be the first thing in the request.
>
> Really?

The grammar has never allowed it.
I can't find any evidence of a decision on this, which is why I'm bring 
it to the WG's attention.

> I thought the intention was to be able to issue requests like:

s/request/operation/ ?

We aren't providing request boundaries in a single language unit as far 
as I recall.  ISSUE-18 and ISSUE-26 in effect make one HTTP request 
(protocol operation) one SPARQL update request.

>
> PREFIX ...
> INSERT ...
> ;
> PREFIX ...
> INSERT ...
> ;
> ...
>
> if that's not the case then I for one support changing it so it is.
>
> The further implication is that if you do:
>
> PREFIX ...
> INSERT ...
> ;
> INSERT ...
>
> the second INSERT gets to see PREFIXes defined in the first, is that intentional?

Yes.
 >> from that point on in the file

The PREFIX is active from that point in the parsed stream.

	Andy
Received on Friday, 3 September 2010 12:27:38 GMT

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