- From: Steve Harris <steve.harris@garlik.com>
- Date: Fri, 9 Oct 2009 17:35:08 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
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 UTC