Copyright © 2008 Hewlett-Packard Development Company, LP. All Rights Reserved. It is also available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.
This document describes SPARQL/Update, an update language for RDF graphs. It uses a syntax derived form SPARQL. Update operations are performed on a collection of graphs in a Graph Store. Operations are provided to change existing RDF graphs as well as create and remove graphs with the Graph Store.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a member submission, offered by Hewlett-Packard, on behalf of the submitting organizations above.
By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.
SPARQL/Update is a language to express updates to an RDF store. It is intended to be a standard mechanism by which updates to a remote RDF Store can be described, communicated and stored. SPARQL/Update is a companion language to SPARQL and is envisaged to be used in conjunction with the SPARQL query language. The reuse of the SPARQL syntax, in both style and detail, reduces the learning curve for developers and reduces implementation costs.
SPARQL/Update provides the following facilities:
Related work:
SPARQL/Update is not:
Language forms are show as:
INSERT { template } [ WHERE { pattern } ]
[]
indicates an optional part of the syntax. []
are
still used for blank nodes in SPARQL requests.
Italics
indicate an item is some syntax element
derived from SPARQL.
Examples are shown as:
PREFIX dc: <http://purl.org/dc/elements/1.1/> INSERT { <http://example/egbook3> dc:title "This is an example title" }
This section gives some example snippets in the proposed SPARQL/Update language that would be used to update a remote RDF store.
(a) Adding some triples to a graph. The snippet describes two RDF triples to be inserted into the default graph of the RDF store.
PREFIX dc: <http://purl.org/dc/elements/1.1/> INSERT DATA { <http://example/book3> dc:title "A new book" ; dc:creator "A.N.Other" . }
(b) This SPARQL/Update request contains a triple to be deleted and a triple
to be added (used here to correct a book title). The requested change happens in
the named graph identified by the URI http://example/bookStore
.
PREFIX dc: <http://purl.org/dc/elements/1.1/> DELETE DATA FROM <http://example/bookStore> { <http://example/book3> dc:title "Fundamentals of Compiler Desing" } INSERT DATA INTO <http://example/bookStore> { <http://example/book3> dc:title "Fundamentals of Compiler Design" }
(c) The example below has a request to delete all records of old books (with date before year 2000)
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> DELETE { ?book ?p ?v } WHERE { ?book dc:date ?date . FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime ) ?book ?p ?v }
(d) This snippet copies records from one named graph to another named graph based on a pattern
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> INSERT INTO <http://example/bookStore2> { ?book ?p ?v } WHERE { GRAPH <http://example/bookStore> { ?book dc:date ?date . FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime ) ?book ?p ?v } }
(e) An example to move records from one named graph to another named graph based on a pattern
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> INSERT INTO <http://example/bookStore2> { ?book ?p ?v } WHERE { GRAPH <http://example/bookStore> { ?book dc:date ?date . FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime ) ?book ?p ?v } }
DELETE FROM <http://example/bookStore> { ?book ?p ?v } WHERE { GRAPH <http://example/bookStore> { ?book dc:date ?date . FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime ) ?book ?p ?v } }
A Graph Store is a repository of RDF graphs managed by a single service. Like an RDF Dataset operated on by SPARQL, a Graph Store has zero or one unnamed graphs and zero or more named graphs. Unlike an RDF dataset, named graphs can be added or deleted to a graph store.
In the simple case, where there is one default graph and no named graphs, SPARQL/Update is a language for update of a single graph.
If an update service is managing some graph store, then there is no presumption that this exactly corresponds to any RDF dataset offered by some query service. The dataset of the query service may be formed from graphs managed by the update service but the dataset offered by the query can be a subset of the graphs in the update service dataset and the names of those graphs may be different. The composition of the RDF dataset may also change.
SPARQL/Update requests are a sequence of operations. Each request should be treated atomically by a SPARQL/Update service.
If two different update services are managing their respective graph stores share a common graph, there is no presumption that the updates done through one service will be propagated to the other. The behaviour of these services with respect to each other is implementation dependent. It is recommended that such deployment scenarios are avoided.
An implementation must target SPARQL queries on updated graphs if the SPARQL and SPARQL/Update end points are the same.
SPARQL/Update supports two categories of update operations on a Graph Store:
Multiple operations can be packed into requests. The operations of a request are executed in order given.
Graph update operations change existing graphs in the Graph Store but do not create or delete them.
The INSERT DATA
operation adds some triples, which are inline in the
request, into a graph.
The DELETE DATA
operation removes some triples, which are inline in
the request, from a graph
The fundamental pattern-based operation of a graph update is MODIFY
. There are two
restricted forms for INSERT
and DELETE
of triples by
pattern; both are special cases of the
MODIFY
operation. A modify operation consists of a group of triples to be deleted and a
group of triples to be added. The specification of the triples is based on a
query pattern.
The difference between MODIFY
/ INSERT
/ DELETE
and INSERT DATA
/ DELETE DATA
is that INSERT
DATA
and DELETE DATA
do not take a template and pattern. The
DATA
forms require concrete data (no named variables).
Having specific operations means that a request can be streamed so that large,
pure-data, updates can be done.
The LOAD
operation reads the contents of a document representing
a graph into a graph in the graph store.
The CLEAR
operation removes all the triples in a graph.
Insert data into a graph:
INSERT DATA [ INTO <uri> ]* { triples }
Delete data from a graph:
DELETE DATA [ FROM <uri> ]* { triples }
# UPDATE outline syntax : general form: MODIFY [ <uri> ]* DELETE { template } INSERT { template } [ WHERE { pattern } ]
The template
and pattern
forms are as
defined in
SPARQL for construct
templates and graph patterns.
The deletion of the triples happens before the insertion. The pattern in
WHERE
clause is evaluated only once, before the delete part of the operation is
performed. The overall
processing model is that the pattern is executed, the results used to
instantiate the DELETE
template, the deletes performed, the results used again to
instantiate the INSERT
template, and the inserts performed.
The pattern
is evaluated as in a SPARQL query SELECT * WHERE { pattern }
and all the named variables are made available to the INSERT
template
and the DELETE
template for defining the triples to be inserted or
deleted.
The <uri>
clause names the graph in the graph store to be
updated; if omitted, the MODIFY
applies to the unnamed graph.
If the operation is on a graph that does not exist, an error is generated. Graphs are not created by the graph update operations. The graph management operations have to be used to create new graphs.
The DELETE
operation is similar to the MODIFY
operation with
an empty INSERT
template. The graph
URI, if present, must be a valid named graph in the Graph Store.
DELETE [ FROM <uri> ]* { template } [ WHERE { pattern } ]
# Equivalent to MODIFY [ <uri> ]* DELETE { template } INSERT { } [ WHERE { pattern } ]
The INSERT
operation is similar to the MODIFY
operation with
an empty DELETE
template. The graph
URI, if present, must be a valid named graph in the Graph Store. The
CREATE
graph management operator should be used to create a new named
graph in the Graph Store.
INSERT [ INTO <uri> ]* { template } [ WHERE { pattern } ]
#Equivalent to MODIFY [ GRAPH <uri> ]* DELETE { } INSERT { template } [ WHERE { pattern } ]
The LOAD
operation copies all the triples of a remote graph into the
specified graph, or if not specified, the default graph of the Graph Store.
LOAD <remoteURI> [ INTO <uri> ]
The CLEAR
operations removes all the triples of the specified graph
or if not specified, the default graph of the Graph Store. This operation does not remove the graph from the Graph Store.
# Remove all triples. CLEAR [ GRAPH <uri> ]
It has the same effect as:
# Remove all triples. DELETE [ <uri> ] { ?s ?p ?o } WHERE { ?s ?p ?o }
but is a clearer expression of empting a graph.
Graph management operations create and destroy named graphs in the Graph Store.
The default graph in a Graph Store always exists.
CREATE [ SILENT ] GRAPH <uri>
This operation creates a new named graph with a name as specified by the URI. After the successful completion of this operation, the new named graph is available for any further graph update operations with MODIFY, INSERT and DELETE operators.
The SPARQL/Update service generates an error if the graph referred by the
URI already exists unless the keyword SILENT
is present when no error is generated and execution of the sequence of
SPARQL/Update operations continues.
DROP [ SILENT ] GRAPH <uri>
This operation removes the specified named graph from the Graph Store associated with the SPARQL/Update service endpoint. After successful completion of this operation, the named graph is no more available for further graph update operations.
The SPARQL/Update service, by default, is expected to generate an error if the
specified named graph does not exist. If
SILENT
is present, this error is ignored and execution of a
sequence of SPARQL/Update operations continues.
Exposing RDF data for update creates many security issues which any deployment must be aware of, and consider the risks involved. This submission does not describe such issues.
In addition to exposing update services over web technologies, implementers of both systems using SPARQL/Update and servers providing a graph store, must be aware that a string-based language is susceptible to insertion attacks in the construction of SPARQL/Update requests.
Rules from rule 16, Prologue,
are taken from the SPARQL grammar.
Note: This grammar does not use special rules for parsing INSERT DATA/DELETE DATA where only triples, not triple patterns (allowing named variables) are allowed. It assumes the update processor will check template contains only ground triples.