From: Paul Gearon <gearon@ieee.org>

Date: Wed, 2 Dec 2009 20:48:19 -0500

Message-ID: <a25ac1f0912021748g1e9a664ega15cc00779c2bb98@mail.gmail.com>

To: Steve Harris <steve.harris@garlik.com>

Cc: SPARQL Working Group <public-rdf-dawg@w3.org>

Date: Wed, 2 Dec 2009 20:48:19 -0500

Message-ID: <a25ac1f0912021748g1e9a664ega15cc00779c2bb98@mail.gmail.com>

To: Steve Harris <steve.harris@garlik.com>

Cc: SPARQL Working Group <public-rdf-dawg@w3.org>

On Wed, Dec 2, 2009 at 6:32 AM, Steve Harris <steve.harris@garlik.com> wrote: > On 1 Dec 2009, at 21:06, Paul Gearon wrote: > >> The main question on updates seems to be around referring to multiple >> graphs, so these operations are based on that idea. I'll be using some >> common prefixes (foaf:, contact:), so I hope no one minds if I don't >> define them. >> >> I can't recall if I'm supposed to be writing according to a specific >> syntax, so I'll offer a couple of variations. >> >> The first case has one source for pattern matching, and one >> destination for insertion. >> This example copies the contents of one graph into another. >> >> (1) The original form would be: >> >> INSERT INTO <destination> { ?s ?p ?o } >> WHERE { GRAPH <source> { ?s ?p ?o } } >> >> (2) With the recent changes: >> >> WITH <source> >> INSERT INTO <destination> { ?s ?p ?o } >> WHERE { ?s ?p ?o } >> >> >> (3) Or using GRAPH instead of INTO: >> >> WITH <source> >> INSERT { GRAPH <destination> { ?s ?p ?o } } >> WHERE { ?s ?p ?o } > > So, in this case wouldn't INSERT ... FROM be a perfectly reasonable thing to > write? It would have the same meaning as in SELECT, wouldn't it? I'm not sure where you're going here. Are you suggesting using FROM to indicate what the WHERE clause should be resolved against? If so, then sure. However, the advantage of WITH is that it also applies to INSERT and DELETE where no graph is supplied. In that case, the word "FROM" isn't appropriate. WITH is a little more general, even if it's not very pretty. >> (4) Then dropping WITH: >> >> INSERT { GRAPH <destination> { ?s ?p ?o } } >> WHERE { GRAPH <source> { ?s ?p ?o } } >> >> (The last would be valid even if WITH is adopted) >> >> >> === >> >> This example has 2 sources for pattern matching and 1 destination for >> insertion. >> >> To create entries for people in a new graph if they live in London and >> have an email address stored in a separate graph: >> >> (1) >> INSERT INTO <people_graph> { ?person a foaf:Person } >> WHERE { >> GRAPH <address_graph> { >> ?person contact:home [ contact:city "London" ] >> } . GRAPH <mail_graph> { >> ?person foaf:mbox ?mail >> } >> } >> >> (2) >> WITH <address_graph> >> INSERT INTO <people_graph> { ?person a foaf:Person } >> WHERE { >> ?person contact:home [ contact:city "London" ] . >> GRAPH <mail_graph> { ?person foaf:mbox ?mail } >> } >> >> (3) >> WITH <address_graph> >> INSERT { GRAPH <people_graph> { ?person a foaf:Person } } >> WHERE { >> ?person contact:home [ contact:city "London" ] . >> GRAPH <mail_graph> { ?person foaf:mbox ?mail } >> } >> >> (4) >> INSERT { GRAPH <people_graph> { ?person a foaf:Person } } >> WHERE { >> GRAPH <address_graph> { >> ?person contact:home [ contact:city "London" ] >> } . GRAPH <mail_graph> { >> ?person foaf:mbox ?mail >> } >> } >> >> === >> >> This example has multiple sources for pattern matching, multiple >> sources for deletion, and a single destination for insertion. >> >> To delete email addresses from graphs a, b, and c, and insert them >> into a graph called email_graph: >> >> (1) can't be done in one step >> >> (2) >> # WITH is being used on the destination, but could be applied elsewhere >> WITH <email_graph> >> DELETE FROM <a> { ?person foaf:mbox ?email }; >> DELETE FROM <b> { ?person foaf:mbox ?email }; >> DELETE FROM <c> { ?person foaf:mbox ?email }; >> INSERT { ?person foaf:mbox ?email } >> WHERE { >> GRAPH <a> {?person foaf:mbox ?email} >> UNION GRAPH <b> {?person foaf:mbox ?email} >> UNION GRAPH <c> {?person foaf:mbox ?email} >> } >> >> (looks like a good case for FROM NAMED) >> >> (3) >> WITH <email_graph> >> DELETE { GRAPH <a> { ?person foaf:mbox ?email } }; >> DELETE { GRAPH <b> { ?person foaf:mbox ?email } }; >> DELETE { GRAPH <c> { ?person foaf:mbox ?email } }; >> INSERT { ?person foaf:mbox ?email } >> WHERE { >> GRAPH <a> {?person foaf:mbox ?email} >> UNION GRAPH <b> {?person foaf:mbox ?email} >> UNION GRAPH <c> {?person foaf:mbox ?email} >> } > > Wouldn't > > DELETE { > GRAPH <a> { ?person foaf:mbox ?email } > GRAPH <b> { ?person foaf:mbox ?email } > GRAPH <c> { ?person foaf:mbox ?email } > } > INSERT { ?person foaf:mbox ?email } > WHERE { > GRAPH <a> {?person foaf:mbox ?email} > UNION GRAPH <b> {?person foaf:mbox ?email} > UNION GRAPH <c> {?person foaf:mbox ?email} > } > > do the job? Yes it would, and I was tempted to write it as such. But since this variation has the option of using "WITH", then I figured I should shoe-horn it into the example. Besides, the following variation drops the WITH, and I wanted to show that there could be a difference between the two. I'm expecting that WITH (or USING... I still like that word), will be useful when the majority of the INSERTs, DELETEs and pattern matching happen on a single graph. This example is the opposite of that situation, so it doesn't show the potential benefits. >> (4) >> DELETE { GRAPH <a> { ?person foaf:mbox ?email } }; >> DELETE { GRAPH <b> { ?person foaf:mbox ?email } }; >> DELETE { GRAPH <c> { ?person foaf:mbox ?email } }; >> INSERT { GRAPH <email_graph> {?person foaf:mbox ?email } } >> WHERE { >> GRAPH <a> {?person foaf:mbox ?email} >> UNION GRAPH <b> {?person foaf:mbox ?email} >> UNION GRAPH <c> {?person foaf:mbox ?email} >> } >> >> >> Alternatively, instead of the union it could be something like: >> DELETE { GRAPH <?g> { ?person foaf:mbox ?email } }; >> INSERT { GRAPH <email_graph> {?person foaf:mbox ?email } } >> WHERE { >> GRAPH <?g> {?person foaf:mbox ?email} . >> FILTER (?g == <a> || ?g == <b> || ?g == <c>) >> } > > s/<?g>/?g/ Yes, thanks. >> This example has a single source for pattern matching, and multiple >> destinations for insertion: >> >> (1) not possible >> >> (2) >> WITH <people_graph> >> INSERT INTO <email_graph> {?person foaf:mbox ?email }; >> INSERT INTO <name_graph> {?person foaf:name ?name } >> WHERE { >> ?person a foaf:Person >> OPTIONAL { ?person foaf:mbox ?email } >> OPTIONAL { ?person foaf:name ?name } >> } > > Surely variable bindings don't span the ; ? I expected them to come out of the WHERE, so yes, they do. The only binding that occurs in the above example is in the WHERE clause. The INSERTs are just using an already bound set of variables. >> (Have we decided what happens with an unbound value? That entry gets >> skipped? I'm guessing so, but I don't recall it being addressed) > > That's what happens in CONSTRUCT, so it seems logical. Thanks. I'll put that in the document somewhere. >> (3) >> WITH <people_graph> >> INSERT { GRAPH <email_graph> {?person foaf:mbox ?email } }; >> INSERT { GRAPH <name_graph> {?person foaf:name ?name } } >> WHERE { >> ?person a foaf:Person >> OPTIONAL { ?person foaf:mbox ?email } >> OPTIONAL { ?person foaf:name ?name } >> } >> >> (4) >> INSERT { GRAPH <email_graph> {?person foaf:mbox ?email } }; >> INSERT { GRAPH <name_graph> {?person foaf:name ?name } } >> WHERE { >> GRAPH <people_graph> { >> ?person a foaf:Person >> OPTIONAL { ?person foaf:mbox ?email } >> OPTIONAL { ?person foaf:name ?name } >> } >> } > > Again the ; here is confusing. It seems like you only need one INSERT block > if you have the GRAPH syntax. Ah, that's true. I wasn't seeing the forrest for the trees. I'll modify accordingly. PaulReceived on Thursday, 3 December 2009 01:48:59 GMT

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