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

Re: INSERT/DELETE Update syntax

From: Steve Harris <steve.harris@garlik.com>
Date: Fri, 9 Oct 2009 17:35:08 +0100
Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-Id: <F81AB6A0-909B-4E40-AD3A-3DC4284BA0D9@garlik.com>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
On 9 Oct 2009, at 16:46, Seaborne, Andy wrote:

[snip]

>> INSERT {
>>    GRAPH <uri1> { <x> <y> ?a }
>>    GRAPH <uri2> { <a> <b> ?b }
>> }
>> WHERE {
>>    ?a <foo> ?b
>> }
>>
>> which would be less verbose than using the draft syntax, and arguably
>> easier to understand. c.f.
>>
>> INSERT DATA INTO <uri1> {
>>    <x> <y> ?a
>> }
>> WHERE {
>>    ?a <foo> ?b
>> }
>> INSERT DATA INTO <uri2> {
>>    <a> <b> ?b
>> }
>> WHERE {
>>    ?a <foo> ?b
>> }
>
> We still need a DATA keyword to help distinguish bulk update and  
> pattern update.  The alternative is that the pattern must  (if there  
> is a pattern) come before the template.

Yes, Ivan M. pointed that out too, I hadn't realised the significance  
of the DATA keyword. It's a good idea.

> INSERT DATA {
>    GRAPH <uri> { ... some triples ... }
> }
>
> And we will have to be clear that the <uri> is a URI not a variable  
> in that case.

Right, that's a little bit of the pain in the grammar, but very much  
worth it.

> What about
>
> INSERT {
>    GRAPH ?g { ... template ... }
> }
> WHERE { ... pattern ... }
>
> This has complexity : does it create the graph? (pros and cons about  
> automatically creating graphs - some systems might prefer an  
> enforced fixed set of named graphs and now it can't be determined  
> syntactically).  What is ?g is a literal?

Well, one option is that has the same rules as CONSTRUCT with bNodes  
in the predicate slot and so on, erroring and rejecting that triple.

Personally, I think I'm in favour of being about to construct new  
graphs like that, it maybe feels like a bit too much rope, but it's  
very useful. For e.g. when you want to split down a big RDF file into  
sections based on some pattern (containing the graph URI), and you  
don't know all the URIs ahead of time.

Example:

INSERT {
   GRAPH ?s {
     ?s :name ?name .
     ?s :location [
       geo:lat ?lat ;
       geo:long ?long ;
     ]
   }
}
WHERE {
   ?s :name ?name .
   ?s :location [
     geo:lat ?lat ;
     geo:long ?long ;
   ]
}

>> INSERT {
>>    GRAPH <uri1> { <x> <y> ?a }
>>    GRAPH <uri2> { <a> <b> ?b }
>> }
>> WHERE {
>>    ?a <foo> ?b
>> }
>
> If ?a is a bnode, what happens? :-)

An obvious option is the same rules as per CONSTRUCT. { ?a <foo> ?b }  
can only match triples from the default graph. I don't remember if  
SPARQL says that it's legal for bNodes to exist in more than one  
graph. 4store typically treats the default graph as the union of the  
named graphs, but I've never been quite convinced that that is legal  
per the spec.

The slightly trickier case is:

INSERT {
    GRAPH <uri1> { <x> <y> ?a }
    GRAPH <uri2> { <a> <b> ?b }
}
WHERE {
    GRAPH <uri1> { ?a <foo> ?b }
}

> I suggest that both renaming bnode labels, and choosing not to, are  
> legal.

Hm, I'm not sure about that. It depends whether INSERT is defined as a  
merge, or a union.

Are you proposing leaving it up to the query processor?

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD
Received on Friday, 9 October 2009 16:35:47 GMT

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