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

Re: Example updates

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Fri, 04 Dec 2009 15:35:23 -0500
Message-ID: <4B19728B.6010209@thefigtrees.net>
To: Paul Gearon <gearon@ieee.org>
CC: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Paul Gearon wrote:
> 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.

I picked this piece of this thread to reply to, since it's the closest 
to talking about my particular use cases for RDF datasets in update. I 
laid out my thoughts in general a couple of weeks ago:

http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0503.html

the short of which is that I'd always expected (naively) to see 
something like this for insert/delete:

INSERT INTO <g> { triple patterns }
FROM g1
FROM g2
FROM NAMED g1
FROM NAMED g3
...
WHERE {
}

DELETE OUT OF <g> { triple patterns }
FROM ...
FROM NAMED ...
WHERE ...

or, using the GRAPH notation:

INSERT { GRAPH <g> { triple patterns } }
FROM g1
FROM g2
FROM NAMED g1
FROM NAMED g3
...
WHERE {
}

DELETE { GRAPH <g> { triple patterns } }
FROM ...
FROM NAMED ...
WHERE ...

(I prefer the GRAPH syntax, as it nicely parallels Glitter's extension 
to CONSTRUCT for quads.)

Here I wanted to give a few ideas of the types of use cases that we'd 
use RDF datasets for in this manner.

Anzo uses a quad store, often with hundreds of thousands or more graphs 
in it. The applications we write against an Anzo store constrain the 
scope of their queries via an RDF dataset. When we begin using SPARQL 
Update, I'd expect this to be no different. So we'd want to be able to:

1/ Use GRAPH ?g constructs over a limited set of graphs in the store.

Example: An application maintains a list of graphs (g1, g2, ..., gn) 
with inventory data for a particular storefront. Other graphs in the 
same store hold data from other store fronts and other uses altogether. 
We want to updates the one store front's data to mark a particular line 
of products as discontinued.

INSERT {
   GRAPH ?g {
     ?product ex:status ex:Discontinued .
   }
FROM NAMED <g1>
FROM NAMED <g2>
...
FROM NAMED <gn>
WHERE {
   GRAPH ?g {
     ?product a ex:Product ;
       ex:ProductLine ex:Line1 ;
     .
   }
}

2/ Query over the RDF union of a limited set of graphs in the store

Example: Same scenario as above. We want to update products from certain 
product lines that have certain tags by marking them featured. The tags 
themselves can be in product graphs (if generated from our product 
catalog) or in user graphs (if user-generated), so the easiest way is to 
use the SPARQL default graph. Assume the user-graphs are u1...un and 
we're doing this again only in the context of a single storefront:

INSERT {
   GRAPH ?product {
     ?product ex:status ex:Featured .
   }
FROM  <g1>
FROM  <g2>
...
FROM  <gn>
FROM  <u1>
...
FROM  <un>
WHERE {
   ?product a ex:Product ;
     ex:ProductLine ex:Line1 ;
     ex:tag tag:Winter .
}


Lee
Received on Friday, 4 December 2009 20:36:11 GMT

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