W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

SPARQL update and datasets

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Thu, 25 Mar 2010 01:40:00 -0400
Message-ID: <4BAAF730.3020902@thefigtrees.net>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
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 05:40:49 GMT

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