SPARQL 1.1 Update

1 Introduction

SPARQL 1.1 Update is a language to express updates to an Graph Store. It is intended to be a standard language for specifying and executing updates to RDF graphs in a Graph Store. SPARQL 1.1 Update is a companion language to SPARQL and is envisaged to be used in conjunction with the SPARQL 1.1 Query language.

SPARQL 1.1 Update provides the following facilities:

Insert new triples into an RDF graph.
Delete triples from an RDF graph.
Perform a group of update operations as a single action.
Create a new RDF graph in a Graph Store.
Delete an RDF graph from a Graph Store.

For the rationale behind this language, see the original SPARQL New Features and Rationale document.

This document is related to the following other specification documents:

The SPARQL 1.1 Uniform HTTP Protocol for Managing RDF graphs specification employs the HTTP protocol to perform update operations using standard HTTP methods, such as PUT and DELETE. While providing a simple and well known API, it is necessarily restricted in its operations due to the limited set of methods in the HTTP protocol. In contrast, SPARQL 1.1 Update permits multiple modifications in a single operation, and can use complex SPARQL queries for constructing data to be inserted, or choosing data to be deleted. Also, the use of an update language facilitates operations over proprietary APIs and connections that may not involve HTTP.

The SPARQL 1.1 Protocol for RDF specification describes a means of conveying SPARQL 1.1 Query and SPARQL 1.1 Update operations from clients to SPARQL endpoints, and for returning appropriate results. Together with the SPARQL 1.1 Query and SPARQL 1.1 Update (this document) specifications, these form an alternative to the SPARQL 1.1 Uniform HTTP Protocol for Managing RDF graphs with comprehensive, though more complex functionality.

1.1 Document Conventions

1.1.1 Language Form

Language forms are show as:

INSERT { ConstructTriples } [ WHERE GroupGraphPattern ]

Here, [] indicates an optional part of the syntax. [] are still used for blank nodes in SPARQL Update requests.

Italics indicate syntactic items derived from the SPARQL Query grammar. BOLD indicates language keywords.

Examples are shown as follows:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT { <http://example/egbook3> dc:title  "This is an example title" }

Data is shown as follows:

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/book/> .
:book1  dc:title  "SPARQL Tutorial" .

1.1.2 Terminology

When this document uses the words must, must not, should, should not, may and recommended, and the words appear as emphasized text, they must be interpreted as described in RFC 2119 [RFC2119].

The following terms are also in use throughout this document:

Operation - A single activity to be performed that results in the modification of data in a graph store. e.g. INSERT or DELETE.
Request - A sequence of one or more operations that are sent to a graph store. When using the SPARQL 1.1 Protocol for RDF a request will be one HTTP POST.

The following terms are also used in this document as defined in the SPARQL 1.1 Query Language

TriplesBlock - A syntactic construct that refers to a set of triples.
ConstructTriples - Identical to a TriplesBlock, but with an emphasis on defining a particular set of triples, rather than finding them.
GroupGraphPattern - A syntactic construct for refering to a set of triples, possibly with complex constraints.

2 The Graph Store

A Graph Store is a repository of RDF graphs managed by a single service. Like an RDF Dataset operated on by the SPARQL 1.1 Query Language, a Graph Store contains one unnamed graph and zero or more named graphs. Operations may specify graphs to work with, or they may rely on a default graph for that operation. Unless overridden (for instance, by the SPARQL protocol), then the unnamed graph for the store will be the default graph for any operations on that store. Depending on implementation, the unnamed graph may refer to a separate graph, or it could be a representation of a union of other graphs.

Unlike an RDF dataset, named graphs can be added to or deleted from a graph store. A Graph Store needs not be authoritative for the graphs it contains, i.e. the graph URIs do not need to be in the same pay level domain as the endpoint. That means a Graph Store can keep local copies of RDF graphs defined elsewhere on the Web and modify those copies independently of the original graph.

In the simple case, where there is one unnamed graph and no named graphs, SPARQL 1.1 Update is a language for the update of a single graph.

A formal definition for graph stores and how SPARQL 1.1 Update affects them is described in the SPARQL 1.1 Update Formal Model section.

2.1 Graph Store and SPARQL Query Services

A service (often referred to as an endpoint) that accepts and processes update operations is referred to as an update service. 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. A query service may offer an RDF dataset formed from graphs that are part of an update service's Graph Store. The graphs in the query service's RDF dataset MAY be a subset of the graphs in the update service's Graph Store. Furthermore, the query service's RDF dataset and the update service's Graph Store may use different names for the same graphs.

2.2 SPARQL 1.1 Update Services

SPARQL 1.1 Update requests are a sequence of operations.

Each request should be treated atomically by a SPARQL 1.1 Update service. Any resulting concurrency issues will be a matter for each implementation to consider according to its own architecture. However, using SERVICE in the WHERE clause of an Update request does not guarantee atomicity.

In the case of two different update services, whose respective graph stores contain graphs with the same names, there is no presumption that the updates done through one service will be propagated to the other, as the stores are independant entities. The behaviour of these services with respect to each other (such as automatic syncronisation after updates) is implementation dependent.

2.2.1 Entailment and Consistency

If the store is capable of calculating entailed statements, c.f. SPARQL 1.1 Entailment Regimes, then it is possible for update operations to interact with entailed data. In particular, a DELETE operation may remove entailed statements. If this is the case, then entailment may generate these statements again, resulting in the statements not being affected of deletions.

After an update is completed, a store that performs consistency checking may check the new state of the data for consistency. If inconsistency is detected, the store should raise an exception.

3 SPARQL 1.1 Update Language

SPARQL 1.1 Update supports two categories of update operations on a Graph Store:

Graph Update - addition and removal of triples from some graphs within the graph store.
Graph Management - creating and deletion of graphs within the graph store.

Multiple operations can be packed into requests. Multiple operations must be separated by a ; (semicolon) character. A sequence of operations is terminated by either a semicolon or EOF (End of File). The operations of a request are executed in lexical order.

Operations all result either in success or failure. A failure result may be accompanied by extra information, indicating that some portion of the operation was successful. This document does not stipulate the exact form of the result, as that will be dependent on the interface being used, for instance the SPARQL 1.1 protocol via HTTP or a programatic API. If multiple operations are present in a single request, then a result of failure from any operation must abort the sequence of operations, causing the subsequent operations to be ignored.

3.1 Graph Update

Graph update operations change existing graphs in the Graph Store but do not explicitly delete nor create them. An implementation must create graphs that do not exist before triples were inserted into them, and may remove graphs that are left empty after triples are removed from them.

The INSERT DATA operation adds some triples, given inline in the request, into a graph. This will create the destination graph if it does not exist.
The DELETE DATA operation removes some triples, given inline in the request, if the respective graph contains those.
The fundamental pattern-based operations for graph updates are INSERT and DELETE. These operations consist of groups of triples to be deleted and groups of triples to be added. The specification of the triples is based on query patterns. The difference between 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.

3.1.1 INSERT DATA

Insert data into a graph:

INSERT DATA { graph_triples }

Graph triples are defined as:

  graph_triples ::= TriplesBlock | GRAPH <uri> { TriplesBlock }

If no graph is described in the graph_triples, then the default graph is presumed. If a graph is described, but it does not exist, then it will be created.

Note that a triple may be considered to be "processed" with no action if that triple already exists in the graph.

Example

Adding some triples to a graph. This snippet describes two RDF triples to be inserted into the default graph of the Graph 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" .
}

Data before:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/book3> ns:price 42 .

Data after:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/book3> ns:price 42 .
<http://example/book3> dc:title "A new book" .
<http://example/book3> dc:creator "A.N.Other" .

An example of INSERT DATA where data is inserted in a named graph (rather than in the default one) is provided in Example 2 of the next section.

3.1.2 DELETE DATA

Delete data from a graph:

DELETE DATA { graph_triples }

graph_triples are described in INSERT DATA.

Note that a triple may be considered to be "processed" with no action if that triple did not exist in the graph.

Note:

What happens if graph_triples contains bnodes still have to be discussed in the document.

Example 1:

Removing undesired triples from a graph. This operation describes 2 triples to be removed from the default graph of the Graph store.

PREFIX dc: <http://purl.org/dc/elements/1.1/>

DELETE DATA
{
  <http://example/bookx> dc:title "David Copperfield" ;
                         dc:creator "Edmund Wells" .
}

Data before:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/bookx> ns:price 42 .
<http://example/bookx> dc:title "David Copperfield" .
<http://example/bookx> dc:creator "Edmund Wells" .

Data after:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/bookx> ns:price 42 .

Example 2:

This SPARQL 1.1 Update request expands on the previous examples, by including a triple to be deleted and a triple to be added (used here to correct a book title). Also, instead of using the default graph, 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
{ GRAPH <http://example/bookStore> { <http://example/book3>  dc:title  "Fundamentals of Compiler Desing" } } ;

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT DATA
{ GRAPH <http://example/bookStore> { <http://example/book3>  dc:title  "Fundamentals of Compiler Design" } }

Data before:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://example/book3> dc:title "Fundamentals of Compiler Desing" .

Data after:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://example/book3> dc:title "Fundamentals of Compiler Design" .

3.1.3 DELETE/INSERT

[ WITH <uri> ]
DELETE { modify_template [ modify_template ]* }
INSERT { modify_template [ modify_template ]* }
[ USING [NAMED] <uri> ]*
[ WHERE ] GroupGraphPattern

The modify_template has the following form:

  modify_template ::= ConstructTriples | graph_template
  graph_template ::= GRAPH VarOrIRIRef { ConstructTriples }

This operation identifies data with the WHERE clause, binding values to a set of variables. These bindings are then used in the DELETE template to remove triples, and then in the INSERT template to create new triples.

The WITH uri defines the graph that will be modified or matched against for any of the subsequent elements that do not specify a graph explicitly. If not provided, then the default graph of the store will be assumed.

Following the optional WITH clause are the INSERT and DELETE clause. The deletion of the triples happens before the insertion. The pattern in the 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 USING <uri> and USING NAMED <uri> clauses affect the graphs and named graphs used in the WHERE clause. This is identical manner to how FROM <uri> and FROM NAMED <uri> clauses affect the graphs and named graphs in a SPARQL SELECT query. The use of USING in this instance is to avoid possible ambiguity of where statements being DELETEd from. If a USING clause appears, then this will override any effect that WITH may have on the WHERE clause, and only the WHERE clause.

As with SELECT queries, the GroupGraphPattern in the WHERE clause will be matched against any graphs described explicitly in that GroupGraphPattern, and any portions which do not specify a graph will be matched against the datasets described with USING or USING NAMED. Any remaining portions of the GroupGraphPattern which are not assigned a dataset will be matched against the graph specified in the WITH clause, if present, or the default graph otherwise.

The GroupGraphPattern is evaluated as in a SPARQL query "SELECT * WHERE GroupGraphPattern" and all the named variables are made available to the preceding templates for defining the triples to be inserted or deleted.

The GRAPH <uri> clause in a graph_template names the graph in the graph store to be updated; if omitted, the INSERT or DELETE clauses applies to the graph specified by the WITH clause, or the default graph if no WITH clause is present.

To illustrate the use of the WITH clause, an operation of the general form:

WITH <g1> INSERT { x y z } DELETE { a b c } WHERE { ... }

Is considered equivalent to:

INSERT { GRAPH <g1> { x y z } } DELETE { GRAPH <g1> { a b c } } USING <g1> WHERE { ... }

Note that WITH will be ignored for any section that stipulates a GRAPH or for the entire WHERE clause if a USING is present.

Deleting triples that are not present, or from a graph that is not present will have no effect and will result in success. Using a new blank node in a delete template will lead to nothing being deleted, as the new blank node cannot match anything that already exists. If an operation tries to insert into a graph that does not exist, then that graph must be created. If no data is to be inserted, then no graph will be created, even if another dataset would result in data being inserted. If an operation intends to create a graph regardless of the data to be inserted, then the graph management operations (CREATE/LOAD) may be used prior to any insertion operations.

Note:

Needs further clarification on blank nodes, as well as on what happens if WITH is not present.

Example:

An example to update the graph http://example/addresses to rename all people with the name "Bill" to "William".

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

WITH <http://example/addresses>
DELETE { ?person foaf:firstName 'Bill' }
INSERT { ?person foaf:firstName 'William' }
WHERE
  { ?person a foaf:Person .
    ?person foaf:firstName 'Bill'
  }

Data before:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "Bill" .

Data after:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "William" .

3.1.4 DELETE

[ WITH <uri> ]
DELETE { modify_template> [ modify_template ]* }
[ USING [NAMED] <uri> ]*
WHERE GroupGraphPattern

The DELETE operation is similar to the DELETE/INSERT operation without an INSERT section. As for DELETE/INSERT, deleting triples that are not present, or from a graph that is not present will have no effect and will result in success.

If any DELETE template specifies a GRAPH then this will be the graph affected. Otherwise, the operation will be applied to the graph specified in the WITH clause, if one was specified, or the default graph otherwise.

The WHERE clause identifies data in existing graphs, and creates bindings to be used by the template. The graphs to apply the GroupGraphPattern to follow the same rules as for DELETE/INSERT.

Example 1:

The example below has a request to delete all records of old books (with date before year 2000) from the store's default graph

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-2:00"^^xsd:dateTime )
   ?book ?p ?v
 }

The pattern in WHERE is matched against the graph store analogously to SPARQL - Query. The resulting variable bindings are used to instantiate the triple patterns in the DELETE template analogously to CONSTRUCT. The resulting triples are then removed from the graph store. If the pattern matching fails, no changes occur.

Data before:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book3> dc:title "Fundamentals of Compiler Design" .
<http://example/book3> dc:date "1996-01-01T00:00:00-2:00" .

<http://example/book> dc:title "SPARQL 1.1 Tutorial" .

<http://example/bookx> ns:price 42 .
<http://example/bookx> dc:title "David Copperfield" .
<http://example/bookx> dc:creator "Edmund Wells" .
<http://example/bookx> dc:date "2002-01-01T00:00:00-2:00" .

Data after:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book> dc:title "SPARQL 1.1 Tutorial" .

<http://example/bookx> ns:price 42 .
<http://example/bookx> dc:title "David Copperfield" .
<http://example/bookx> dc:creator "Edmund Wells" .
<http://example/bookx> dc:date "2002-01-01T00:00:00-2:00" .

Example 2:

An example to remove all statements about anything with a first name of "Fred" from the graph http://example/addresses. A USING clause is present, meaning that the template also serves as the pattern to be matched in the http://example/addresses graph.

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

USING <http://example/addresses>
DELETE { ?person ?property ?value } 
WHERE { ?person foaf:firstName 'Fred' }

Data before:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "William" .
<http://example/william> foaf:mbox "bill@example" .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:firstName "Fred" .
<http://example/fred> foaf:mbox "fred@example" .

Data after:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "William" .
<http://example/william> foaf:mbox "bill@example" .

Another example of DELETE is provided in the final example in the following section which demonstrates multiple operations combining an INSERT with a DELETE.

3.1.5 INSERT

[ WITH <uri> ]
INSERT { modify_template [ modify_template ]* }
[ [ USING [NAMED] <uri> ]*
  WHERE GroupGraphPattern ]

The INSERT operation is equivalent to the DELETE/INSERT operation without a specified DELETE section.

If the INSERT template specifies a GRAPH then this will be the graph affected. Otherwise, the operation will be applied to the graph specified in the WITH clause, if one was specified, or the default graph otherwise. If no WHERE clause is present, then the pattern will be matched in the same way: operating on the GRAPH if one is specified, or else the graph in the WITH clause, or the default graph if no other specifications are used.

The WHERE clause identifies data in existing graphs, and creates bindings to be used by the template. The graphs to apply the GroupGraphPattern to follow the same rules as for DELETE/INSERT.

Example 1:

This example 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 
  { GRAPH <http://example/bookStore2> { ?book ?p ?v } }
WHERE
  { GRAPH  <http://example/bookStore>
       { ?book dc:date ?date .
         FILTER ( ?date < "2000-01-01T00:00:00-2:00"^^xsd:dateTime )
         ?book ?p ?v
  } }

Data before:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book3> dc:title "Fundamentals of Compiler Design" .
<http://example/book3> dc:date "1996-01-01T00:00:00-2:00"

<http://example/book> dc:title "SPARQL 1.1 Tutorial" .

<http://example/bookx> ns:price 42 .
<http://example/bookx> dc:title "David Copperfield" .
<http://example/bookx> dc:creator "Edmund Wells" .
<http://example/bookx> dc:date "2002-01-01T00:00:00-2:00" .

# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book> dc:title "SPARQL 1.0 Tutorial" .

Data after:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book3> dc:title "Fundamentals of Compiler Design" .
<http://example/book3> dc:date "1996-01-01T00:00:00-2:00" .

<http://example/book> dc:title "SPARQL 1.1 Tutorial" .

<http://example/bookx> ns:price 42 .
<http://example/bookx> dc:title "David Copperfield" .
<http://example/bookx> dc:creator "Edmund Wells" .
<http://example/bookx> dc:date "2002-01-01T00:00:00-2:00" .

# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book> dc:title "SPARQL 1.0 Tutorial" .

<http://example/book3> dc:title "Fundamentals of Compiler Design" .
<http://example/book3> dc:date "1996-01-01T00:00:00-2:00" .

Example 2:

An example to copy records from one named graph to another named graph based on a pattern. All the copied objects that are also classified as Physical Objects are then deleted. This demonstrates two operations in a single request, both of which share common PREFIX definitions.

PREFIX dc:  <http://purl.org/dc/elements/1.1/>
PREFIX dcmitype: <http://purl.org/dc/dcmitype/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT
  { GRAPH <http://example/bookStore2> { ?book ?p ?v } }
WHERE
  { GRAPH  <http://example/bookStore>
     { ?book dc:date ?date . 
       FILTER ( ?date < "2000-01-01T00:00:00-2:00"^^xsd:dateTime )
       ?book ?p ?v
     }
  } ;

WITH <http://example/bookStore>
DELETE
 { ?book ?p ?v }
WHERE
 { ?book dc:date ?date ;
         dc:type dcmitype:PhysicalObject .
   FILTER ( ?date < "2000-01-01T00:00:00-2:00"^^xsd:dateTime ) 
   ?book ?p ?v
 }

Data before:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/>

<http://example/book3> dc:title "Fundamentals of Compiler Design" .
<http://example/book3> dc:date "1996-01-01T00:00:00-2:00"
<http://example/book3> a dcmitype:PhysicalObject .

<http://example/book> dc:title "SPARQL 1.1 Tutorial" .

# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book> dc:title "SPARQL 1.0 Tutorial" .

Data after:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/>

<http://example/book> dc:title "SPARQL 1.1 Tutorial" .

# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/>

<http://example/book> dc:title "SPARQL 1.0 Tutorial" .

<http://example/book3> dc:title "Fundamentals of Compiler Design" .
<http://example/book3> dc:date "1996-01-01T00:00:00-2:00"
<http://example/book3> a dcmitype:PhysicalObject .

3.1.6 DELETE WHERE

DELETE WHERE { modify_template [ modify_template ]* }

The DELETE WHERE operation is similar to the DELETE/INSERT operation where the triples matched by the WHERE clause will be the triples deleted. As for DELETE/INSERT, deleting triples that are not present, or from a graph that is not present will have no effect and will result in success.

The modify_template is used both as a GroupGraphPattern and as the template for deletion. The form for modify_template is described in DELETE/INSERT. If any modify_template specifies a GRAPH then this will be the graph that that template is matched on, and also the graph from which any matching triples will be removed. Any templates without a GRAPH statement will be applied to the default graph.

Example 1:

An example to remove all statements about anything with a first name of "Fred" from the default graph.

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

DELETE WHERE { ?person foaf:firstName 'Fred';
                       ?property      ?value }

Data before:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "William" .
<http://example/william> foaf:mbox "bill@example" .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:firstName "Fred" .
<http://example/fred> foaf:mbox "fred@example" .

Data after:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "William" .
<http://example/william> foaf:mbox "bill@example" .

Example 2:

Find and remove statements naming something "Fred" in the graph http://example.com/names, and also remove all statements about that resource from the graph http://example/addresses.

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

DELETE WHERE {
  GRAPH <http://example.com/names> {
    ?person foaf:firstName 'Fred'
  } .
  GRAPH <http://example.com/addresses> {
    ?person ?property ?value
  }
}

# Graph: http://example.com/names
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "William" .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:firstName "Fred" .

# Graph: http://example.com/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> foaf:mbox "bill@example" .

<http://example/fred> foaf:mbox "fred@example" .

Data after:

# Graph: http://example.com/names
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> a foaf:Person .
<http://example/william> foaf:firstName "William" .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:firstName "Fred" .

# Graph: http://example.com/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/>

<http://example/william> foaf:mbox "bill@example" .

3.1.7 LOAD

The LOAD operation copies all the triples of a remote graph into the specified graph.

LOAD [ SILENT ] <documentURI> [ INTO GRAPH <uri> ]

The documentURI specifies the URI of a document such that a store will be able to identify, locate and read the document. Common forms will be URLs with the http or file protocols. Once the document has been read, the resulting triples will be inserted into the destination graph.

If no destination graph URI is provided to load the triples into, then the data will be loaded into the default graph.

In case no RDF data can be retrieved from documentURI, the SPARQL 1.1 Update service is expected to return failure. In any other case, it will always return success. If SILENT is present, the result of the operation will always be success.

3.1.8 CLEAR

CLEAR  [ SILENT ] (GRAPH <uri> | DEFAULT | NAMED | ALL )

The CLEAR operation removes all the triples of the specified graph. The DEFAULT keyword is used to remove all triples of the default graph of the Graph Store, the NAMED keyword is used to remove all triples of all named graphs of the Graph Store and the ALL keyword is used to remove all triples of all graphs of the Graph Store. This operation is not required to remove the empty graphs from the Graph Store, but an implementation may decide to do so.

# Remove all triples from a specified graph.
CLEAR GRAPH <uri>

has the same effect as:

# Remove all triples from the graph uri.
WITH <uri> DELETE { ?s ?p ?o } WHERE { ?s ?p ?o }

Note:

For services which form the default graph from the unions of other graphs then CLEAR DEFAULT may have far reaching implications.

If the store records the existence of empty graphs, then the SPARQL 1.1 Update service, by default, is expected to return failure if the specified graph does not exist. If SILENT is present, the result of the operation will always be success.

Stores that do not record empty graphs will always return success.

3.2 Graph Management

Graph management operations create and destroy named graphs in the Graph Store. These operations are not required to result in any actions, since graph stores are not required to support named graphs.

The default graph in a Graph Store always exists.

3.2.1 CREATE

CREATE [ SILENT ] GRAPH <uri>

For stores that record empty graphs, this will create a new empty graph in the store with a name specified by the URI. If the graph already exists, then a failure may be returned, except when the SILENT keyword is used.

Stores that do not record empty graphs will always return success.

3.2.2 DROP

DROP  [ SILENT ] (GRAPH <uri> | DEFAULT | NAMED | ALL )

The DROP operation removes the specified graph from the Graph Store. The DEFAULT keyword is used to remove the default graph from the Graph Store, the NAMED keyword is used to remove all named graphs from the Graph Store and the ALL keyword is used to remove all graphs from the Graph Store, i.e. reseting the store. After successful completion of this operation, the graph is no longer available for further graph update operations. However, in case the DEFAULT graph of the Graph Store is dropped, implementations MUST restore it after it was removed.

If the store records the existence of empty graphs, then the SPARQL 1.1 Update service, by default, is expected to return failure if the specified named graph does not exist. If SILENT is present, the result of the operation will always be success.

Stores that do not record empty graphs will always return success.

4 SPARQL Update Formal Model

Note:

The following formalisation of the SPARQL update operations is a first draft, reflecting the intuition behind the different update operations, while not yet formalised completely in terms of precisely defining the pseudo-mathematical notation used. Future versions of this document shall provide a full formalisation

4.1 General Definitions

4.1.1 GraphStore

Definition: GraphStore

A GraphStore GS is a mutable container of RDF graphs. It has one unnamed (default) slot and zero or more named slots identified by an IRI . Each slot holds an RDF graph.

GS = (DG, {(, G_i)})

where:

DG is the RDF graph associated to the unnamed slot
G_i is an RDF graph associated to the named slot identified by IRI

4.1.2 GraphStoreState

Definition: GraphStoreState

A GraphStoreState GSS_t is a function returning the state of a Graph Store GS at particular time t.

GSS_t(GS) = (S_t(DG), {(, S_t(G_i)})

where:

S_t(DG) is the state of DG at time t, i.e. the triples it contains (if any)
S_t(G_i) is the state of G_i at time t, i.e. the triples it contains (if any)

4.1.3 UpdateOperation

Definition: UpdateOperation

An UpdateOperation Op is a function from a GSS to a GSS, that can accept some arguments. This is an atomic operation from time t to t+1, no other operations happening between t and t+1. A sequence of UpdateOperation leads to t being incremented several times. An UpdateOperation can create new slots and new RDF graphs, or can remove existing slots and the corresponding graphs. It can also alter the state of each graph individually.

Op(GSS_t(GS), [ARGS]) = GSS_t+1(GS)

4.2 Graph Update Operations

4.2.1 InsertDataOperation

Definition: InsertDataOperation

A InsertDataOperation OpInsertData is an UpdateOperation in which new triples are added in the GraphStore, either in the default slot or in named slot(s).

OpInsertData(GSS_t(GS), {triples}, {(, triples_i)}) = GSS_t(GS) UNION ({triples}, {(, triples_i)})

4.2.2 DeleteDataOperation

Definition: DeleteDataOperation

A DeleteDataOperation OpDeleteData is an UpdateOperation in which triples are removed from the GraphStore, either from the default slot or from named slot(s).

OpDeleteData(GSS_t(GS), {triples}, {(, triples_i)}) = GSS_t(GS) MINUS ({triples}, {(, triples_i)})

4.2.3 DeleteInsertOperation

Definition: DeleteInsertOperation

A DeleteInsertDataOperation OpDeleteInsert is an UpdateOperation in which (1) triples are deleted from the GraphStore, either from the default slot or from named slot(s), and then (2) new triples are added in the GraphStore, either in the default slot or in named slot(s). Triples are identified as they match a particular Group Graph Pattern GGP.

OpDeleteInsert(GSS_t(GS), {d_triples}, {(, d_triples_i)}, {a_triples}, {(, a_triples_i)}, GGP) = GSS_t(GS) MINUS ({d_triples}, {(, d_triples_i)}) UNION ({a_triples}, {(, a_triples_i)})

4.2.4 DeleteOperation

Definition: DeleteOperation

A DeleteOperation OpDelete is an UpdateOperation in which triples are deleted from the GraphStore, either from the default slot or from named slot(s). Triples are identified as they match a particular Group Graph Pattern GGP.

OpDelete(GSS_t(GS), {d_triples}, {(, d_triples_i)}, GGP) = GSS_t(GS) MINUS ({d_triples}, {(, d_triples_i)})

4.2.5 InsertOperation

Definition: InsertOperation

A InsertOperation OpInsert is an UpdateOperation in which new triples are added in the GraphStore, either in the default slot or in named slot(s). Triples are identified as they match a particular Group Graph Pattern GGP.

OpInsert(GSS_t(GS), {a_triples}, {(, a_triples_i)}, GGP) = GSS_t(GS) UNION ({a_triples}, {(, a_triples_i)})

4.2.6 DeleteWhereOperation

Definition: DeleteWhereOperation

A DeleteWhereOperation OpDeleteWhere is an UpdateOperation in which triples are deleted from the GraphStore, either from the default slot or from named slot(s). Triples are identified as they match a particular Group Graph Pattern GGP.

OpDeleteWhere(GSS_t(GS), GGP) = GSS_t(GS) MINUS ({triples}, {(, triples_i)})

where:

triples (and triples_i) are triples matching the GGP

4.2.7 LoadOperation

Definition: LoadOperation

A LoadOperation OpLoad is an UpdateOperation in which new triples (from a remote graph) are added in the GraphStore, either in the default slot or in a named slot, if specified

OpLoad(GSS_t(GS), <remote>) = GSS_t(GS) UNION ({triples_remote})

OpLoad(GSS_t(GS), <remote>, <local>) = GSS_t(GS) UNION {(<local>, triples_remote)}

4.2.8 ClearOperation

Definition: ClearOperation

A ClearOperation OpClear is an UpdateOperation in which triples are removed from deleted from the GraphStore, from existing slots (a single slot , the default slot, all named slots, all slots).

OpClear(GSS_t(GS), ) = (S_t(DG), {(<i-1>, S_t(G_i-1)}, {(, {})}

i.e. triples from the graph assigned to slot are removed

OpClear(GSS_t(GS), DEFAULT) = ({}, {(, S_t(G_i)})

i.e. triples from the graph assigned to the default slot are removed

OpClear(GSS_t(GS), NAMED) = (S_t(DG), {(, {})}

i.e. triples from the graphs assigned to named slots are removed

OpClear(GSS_t(GS), ALL) = ({}, {(, {})}

i.e. triples from all graphs are removed

4.3 Graph Management Operations

4.3.1 CreateOperation

Definition: CreateOperation

A CreateOperation OpCreate is an UpdateOperation in which (1) a new named slot and (2) a new graph are created in the GraphStore. The new graph is held in the new slot. Other slots and graphs are not affected.

OpCreate(GSS_t(GS), ) = (GSS_t(GS) UNION (, {}))

4.3.2 DropOperation

Definition: DropOperation

A DropOperation OpDrop is an UpdateOperation in which (1) one or more existing slots (a single slot , the default slot, all named slots, all slots) and (2) the corresponding graph(s) are removed from the GraphStore.

OpDrop(GSS_t(GS), ) = (S_t(DG), {(<i-1>, S_t(G_i-1)})

i.e. the slot and the corresponding graph are removed

OpDrop(GSS_t(GS), DEFAULT) = ({}, {(, S_t(G_i)})

i.e. the graph associated to the unnamed slot is emptied but graphs associated to named slots are not affected

OpDrop(GSS_t(GS), NAMED) = (S_t(DG), {()})

i.e. all named slots and corresponding graphs are removed but the graph associated with the default slot is not altered

OpDrop(GSS_t(GS), ALL) = ({}, {()})

i.e. all named slots and corresponding graphs are removed, and the default graph is emptied

5 Conformance

See appendix B SPARQL 1.1 Update Grammar regarding conformance of SPARQL Update strings.

This specification is intended for use in conjunction with: the SPARQL 1.1 Uniform HTTP Protocol for Managing RDF graphs and the SPARQL 1.1 Protocol for RDF.

A Security Considerations

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 1.1 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 1.1 Update requests.

Issue (ISSUE-19):

Security issues on SPARQL/Update

Source: ISSUE-19

Resolution:

None recorded.

B SPARQL 1.1 Update Grammar

The operations described in this document are indicative only. The formal definition for the SPARQL 1.1 Update grammar is provided with the SPARQL 1.1 Query grammar. This is because the grammar for SPARQL 1.1 Update shares most of its structure with SPARQL 1.1 Query.

C References

C.1 Normative References

IANA-CHARSETS: (Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. (See http://www.iana.org/assignments/character-sets.)

C.2 Other References

Aho/Ullman: Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
Brüggemann-Klein: Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993. (See ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein and Wood: Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Full version titled One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, February 1998.
Clark: James Clark. Comparison of SGML and XML. (See http://www.w3.org/TR/NOTE-sgml-xml-971215.)
IANA-LANGCODES: (Internet Assigned Numbers Authority) Registry of Language Tags (See http://www.iana.org/assignments/language-subtag-registry.)
IETF RFC 2141: IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997. (See http://www.ietf.org/rfc/rfc2141.txt.)
IETF RFC 3023: IETF (Internet Engineering Task Force). RFC 3023: XML Media Types. eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)
IETF RFC 2781: IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)
ISO 639: (International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.
ISO 3166: (International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions — Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.
ISO 8879: ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing — Text and Office Systems — Standard Generalized Markup Language (SGML). First edition — 1986-10-15. [Geneva]: International Organization for Standardization, 1986.
ISO/IEC 10744: ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology — Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.
WEBSGML: ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology — Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (See http://www.sgmlsource.com/8879/n0029.htm.)
XML Names: Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/xml-names/.)

D CVS History

$Log: Overview.html,v $ Revision 1.3 2010/10/13 17:25:39 apollere2 Added:

This is a Working Draft.

Revision 1.2 2010/10/13 12:42:19 apassant Removed ED sentence Revision 1.1 2010/10/08 05:39:38 apollere2 Moved file index.html to Overview.html Revision 1.3 2010/10/08 05:37:23 apollere2 Fix in wrong "previous version URI. Revision 1.2 2010/10/08 05:35:31 apollere2 Changed to final This version and previous version links. Revision 1.1 2010/10/07 08:58:20 apassant Added update ready for publication Revision 1.11 2010/10/07 08:50:33 apassant Updated for publication Revision 1.10 2010/10/07 08:45:24 apassant Updated for publication Revision 1.9 2010/10/07 08:44:24 apassant Updated for publication Revision 1.8 2010/10/07 08:42:00 apassant Updated for publication Revision 1.7 2010/10/07 07:37:48 apassant Updated for publication Revision 1.71 2010/10/07 07:33:03 apassant Updated XML entities for publication Revision 1.70 2010/10/07 07:28:16 apassant Added editor notes on Formal Model and WITH before publishing Revision 1.69 2010/10/07 07:24:12 apassant Added editor notes on Formal Model and WITH before publishing Revision 1.68 2010/10/07 07:09:01 apassant Updated as per Axel's reply Revision 1.67 2010/10/06 17:45:44 apassant Fixed broken links Revision 1.66 2010/10/06 17:13:47 apassant Fixed XHTML Revision 1.65 2010/10/03 10:18:17 apassant Proofreading formal model Revision 1.64 2010/10/03 10:09:32 apassant Updated text on SERVICE and ATOMICITY Revision 1.63 2010/10/03 10:08:34 apassant s/graph_uri/uri in the INSERT DATA section Revision 1.61 2010/09/30 22:43:14 apassant First pass on Axel's review Revision 1.60 2010/09/30 22:26:16 apassant Removed 'outstanding issues' section Revision 1.59 2010/09/30 22:25:24 apassant Closed ISSUE-37 Revision 1.58 2010/09/29 17:26:35 apassant Minor edits (style changes, removed comments) Revision 1.57 2010/09/29 17:13:22 apassant Added data before / after for each examples Revision 1.56 2010/09/29 15:53:57 apassant Formal model for Graph Update Operations Revision 1.55 2010/09/03 14:55:46 apassant Added LHS argments in formal operations Revision 1.54 2010/08/31 12:43:33 apassant s/directive/clause Revision 1.53 2010/08/31 11:39:36 apassant Updating formal update definition + minor typos Revision 1.52 2010/08/30 16:29:47 apassant Formal model: general definitions and graph management operations Revision 1.51 2010/08/30 10:53:29 apassant fixing typos and removing old content Revision 1.50 2010/08/11 14:19:46 pgearon Removed reference to clearing default graphs by default, since this is now an explicit operation. Revision 1.49 2010/07/16 16:31:01 apassant Updated CLEAR and DROP with DEFAULT | NAMED | ALL and SILENT Revision 1.48 2010/06/02 06:11:41 apassant Fixed broken links Revision 1.47 2010/05/18 21:34:42 pgearon Updated DELETE WHERE to remove WITH and specify templates instead of a full GroupGraphPattern Revision 1.46 2010/05/18 21:13:01 pgearon Updated following Lee's review. Also added DELETE WHERE section Revision 1.45 2010/05/18 14:20:21 pgearon Removed result descriptions from individual operations Revision 1.44 2010/05/17 09:28:33 apassant Updated document following Lee's review Revision 1.43 2010/05/06 17:29:54 pgearon Updated LOAD and CLEAR to explicitly refer to the DEFAULT graph Revision 1.42 2010/05/06 02:43:24 pgearon Added a link to the Query grammar in Appendix B, for the update grammar. USING/USING-NAMED has been added to DELETE-WHERE and INSERT-WHERE. Return codes have been added to each operation. Revision 1.41 2010/04/30 16:15:21 pgearon Reverted last change. WITH duplicates GRAPH for DATA updates Revision 1.40 2010/04/30 15:02:04 pgearon Added WITH to INSERT DATA and DELETE DATA Revision 1.39 2010/04/28 03:12:43 pgearon Added statement on model of update. Provided example of equivalence to the use of WITH. Mentioned semicolon terminators. Changed the name of INSERT/DELETE to DELETE/INSERT to reflect usage. Removed ISSUE 51, and introduced USING/USING NAMED. Revision 1.38 2010/03/29 21:05:21 pgearon - Commented that CREATE/DROP may be at risk. - Multiple commands require ; separator. - CLEAR can now be used on the default graph. - Cleared up usage of "default graph" and "unnamed graph". - Added explanation that multiple operations in a request SHOULD be executed atomically. Provided examples where this may not be feasible. - Comment on the relationship between atomicity and concurrency. - Added comment on deleting entailed data. - Added comment on needing to perform consistency checking at the end of and update operation. Revision 1.37 2010/03/16 18:27:25 pgearon Added comment allowing anonymous blank nodes in short-form delete Revision 1.36 2010/03/16 05:20:05 pgearon Added a comment about not using blank nodes in the short-form DELETE operation Revision 1.35 2010/03/16 05:01:48 pgearon INSERT operations may now create a graph Revision 1.34 2010/01/27 01:23:31 apollere2 Removed div2 in CVS history that had a problematic effect on the generated TOC. Revision 1.33 2010/01/22 01:42:05 apollere2 Adapted shortname. Revision 1.32 2010/01/22 01:37:25 apollere2 Changed date to 26. Revision 1.31 2010/01/19 15:24:10 pgearon Added ISSUE-51 Revision 1.30 2010/01/19 15:05:03 pgearon Fixed typo Revision 1.29 2010/01/19 01:41:43 pgearon Removed extra ; character from DELETE/INSERT example in 4.1.2 Revision 1.28 2010/01/18 20:30:00 pgearon Removed duplicate reference to ISSUE-19 and reference to ISSUE-21 as it has now been closed Revision 1.27 2010/01/18 20:15:07 pgearon updated a duplicated ID Revision 1.26 2010/01/18 20:12:46 pgearon Removed semicolon from DELETE/INSERT statements Revision 1.25 2010/01/15 19:15:35 pgearon Added a Terminology section. Removed Property Paths now that issue 38 has been resolved. Included reference to RFC 2119 terminology and added emphasized SHOULD and OPTIONAL comments. Added note on discussion of blank nodes in DELETE templates. Added note on discussion of INSERTs creating new graphs. Added note on ambiguity around DELETE/INSERT and DELETE statements. Added note on need to mention partially completed LOAD operations. Added OPTIONAL description for graph management operations. Revision 1.24 2010/01/07 22:17:44 pgearon Finished updates recommended by AxelP Revision 1.23 2010/01/07 18:34:12 pgearon Finished updates recommended by AndyS Revision 1.22 2010/01/05 01:33:43 pgearon Some up the cleanups requested by Andy, including commenting out the grammar Revision 1.21 2009/12/19 03:36:00 pgearon Updated the date Revision 1.20 2009/12/19 03:30:20 pgearon Updated to go from INSERT-INTO/DELETE-FROM to GRAPH {template} constructs Revision 1.19 2009/12/01 02:02:47 pgearon Removed extraneous parenthesis Revision 1.18 2009/12/01 01:47:32 pgearon Cleaned up syntax a little for INSERT/DELETE Revision 1.17 2009/11/30 23:14:55 pgearon First attempt at INSERT/DELETE syntax. Not happy wiht this still Revision 1.16 2009/10/21 03:35:31 lfeigenb publication prep Revision 1.15 2009/10/20 20:50:37 lfeigenb validation errors Revision 1.14 2009/10/20 19:45:52 lfeigenb small fixes for naming and cleanup Revision 1.13 2009/10/20 19:10:19 lfeigenb Fixed and added support for markup that was previously unsupported by our XSLTs. Future SPARQL-specific customizations should go in shared/sparql.xsl Revision 1.12 2009/10/20 14:40:52 pgearon Removed reference to ISSUE-22 Revision 1.11 2009/10/20 07:45:16 sschenk turned notes into issues: ISSUES 45-48 Revision 1.10 2009/10/17 15:05:21 pgearon changed cvs log details as it included some half baked html Revision 1.9 2009/10/16 21:54:54 pgearon Updates as per email from Luke Wilson-Mawer on October 16, 2009. Also converted to and removed from the grammar. Revision 1.8 2009/10/15 09:42:40 sschenk address comments in http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0041.html Revision 1.7 2009/10/14 10:07:02 sschenk zero modification commit to fix R1.6 commit message Revision 1.6 2009/10/14 09:36:53 sschenk convert all @@todos into issue or note Revision 1.5 2009/10/13 10:20:40 sschenk restructuring and section renaming Revision 1.4 2009/10/11 19:53:47 sschenk Add dtd, xsls for update, update grammar Revision 1.1 2009/09/14 21:17:28 eric CREATED

SPARQL 1.1 Update

W3C Working Draft 14 October 2010

Abstract

Status of this Document

Table of Contents

Appendices

1 Introduction

1.1 Document Conventions

1.1.1 Language Form

1.1.2 Terminology

2 The Graph Store

2.1 Graph Store and SPARQL Query Services

2.2 SPARQL 1.1 Update Services

2.2.1 Entailment and Consistency

3 SPARQL 1.1 Update Language

3.1 Graph Update

3.1.1 INSERT DATA

3.1.2 DELETE DATA

3.1.3 DELETE/INSERT

3.1.4 DELETE

3.1.5 INSERT

3.1.6 DELETE WHERE

3.1.7 LOAD

3.1.8 CLEAR

3.2 Graph Management

3.2.1 CREATE

3.2.2 DROP

4 SPARQL Update Formal Model

4.1 General Definitions

4.1.1 GraphStore

4.1.2 GraphStoreState

4.1.3 UpdateOperation

4.2 Graph Update Operations

4.2.1 InsertDataOperation

4.2.2 DeleteDataOperation

4.2.3 DeleteInsertOperation

4.2.4 DeleteOperation

4.2.5 InsertOperation

4.2.6 DeleteWhereOperation

4.2.7 LoadOperation

4.2.8 ClearOperation

4.3 Graph Management Operations

4.3.1 CreateOperation

4.3.2 DropOperation

5 Conformance

A Security Considerations

B SPARQL 1.1 Update Grammar

C References

C.1 Normative References

C.2 Other References

D CVS History