Re: Example updates

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.

Paul

Received on Thursday, 3 December 2009 01:48:59 UTC