Re: SPARQL update and datasets

What is not entirely  clear to me is how that treats the corner case mentioned at:
  http://www.w3.org/2009/sparql/meeting/2010-03-09#line0159
i.e. do I understnad correctly that you mean that the FROM/FROM only affect the query part dataset, but
that inserts without GRAPH specified still go to the unnamed graph.

Axel

On 25 Mar 2010, at 05:40, Lee Feigenbaum wrote:

> This is in reference to http://www.w3.org/2009/sparql/track/actions/202
> . It's not a complete proposal, but has most elements of one. I have not
> discussed this with Paul.
> 
> 1/ Add FROM and FROM NAMED clauses to the INSERT/DELETE update form(s)
> in the same syntactic location and with the same semantics as SPARQL
> Query. This means:
> 
> # UPDATE outline syntax : general form:
> [ WITH <uri> ]
> DELETE { modify_template [ modify_template ]* }
> INSERT { modify_template [ modify_template ]* }
> [ FROM <uri> ]
> [ FROM <uri> ]
> ...
> [ FROM NAMED <uri> ]
> [ FROM NAMED <uri> ]
> ...
> WHERE GroupGraphPattern
> 
> The FROM and FROM NAMED clauses together specify an RDF Dataset. The
> default graph of the RDF Dataset is the RDF merge of the graphs
> identified in the FROM clauses. (This is as in SPARQL query.) All
> pattern matching in the GroupGraphPattern is performed against this RDF
> Dataset as per SPARQL Query semantics.
> 
> I'd _like_ to be able to say that the RDF Dataset is a subset of the
> Graph Store, but given that the Graph Store defines a single unnamed
> graph whereas the RDF Dataset allows me to craft a default graph as the
> merge of multiple graphs, I don't know how to formally specify this
> subset relationship.
> 
> 2/ Deal with the confusion between WITH and FROM/FROM NAMED by removing
> WITH entirely.
> 
> On a recent teleconference, someone asked what the relationship between
> WITH and FROM/FROM NAMED would be. My gut reaction was:
> 
>    -- WITH gives the default graph for the INSERT and DELETE templates,
> while FROM/FROM NAMED give the graphs for the query pattern.
> 
> I still think this is workable, but I also think it is confusing at
> best. Instead I would propose:
> 
>    * No WITH clause.
>    * Triple patterns within a template that are not within a GRAPH
> clause are inserted into / deleted from the query's default graph. This
> graph is determined as follows:
>      * If the query has a single FROM clause, that is the default graph
>      * If the query has no FROM clause, the default graph is the Graph
> Store's unnamed graph (implementation defined)
>      * If the query has multiple FROM clauses, the query is an error
> and/or undefined.
> 
> In my mind, this would make SPARQL Update treat graphs and datasets in
> basically the same way as SPARQL Query, with the distinction that the
> template part of the update statements can refer to graphs not in the
> RDF Dataset by means of a GRAPH clause.
> 
> WITH g1
> INSERT { x y z }
> DELETE { a b c }
> FROM g2
> WHERE { ... }
> 
> becomes
> 
> INSERT { GRAPH g1 { x y z } }
> DELETE { GRAPH g1 { a b c } }
> FROM g2
> WHERE { ... }
> 
> To me, this _slightly_ more verbose form is well worth removing the new
> WITH construct and unifying the dataset semantics of SPARQL Query and
> SPARQL Update.
> 
> 3/ As with SPARQL Query, if no FROM or FROM NAMED is given, then the
> dataset is determined by the implementation. (I suspect this is just as
> in the update draft now - the dataset in this case is the Graph Store.)
> 
> This means that a query like the example in 4.1.4 works by changing the
> WITH into a GRAPH clause. That is:
> 
> PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
> WITH <http://example/addresses>
> DELETE WHERE {
>    ?person foaf:firstName 'Fred';
>            ?property      ?value
> }
> 
> would become:
> 
> PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
> DELETE WHERE {
>   GRAPH <http://example/addresses> {
>    ?person foaf:firstName 'Fred';
>            ?property      ?value
>   }
> }
> 
> ...which, if we're counting characters, is 3 characters longer.
> 
> Anyway, we can discuss later at the face-to-face, and my apologies for
> the very late nature of this proposal.
> 
> Lee
> 
> 
>

Received on Thursday, 25 March 2010 10:39:07 UTC