SPARQL 1.1 Update

1.1.1 Language Form

The operations in this document contain language forms describing their use. These are meant as illustrative forms of the formal grammar described in the SPARQL 1.1 Query document. Any discrepancies between the language forms in this document and the grammar in SPARQL 1.1 Query will defer to the formal grammar in SPARQL 1.1 Query.

Language forms are shown informally in this document as for instance:

( WITH IRIref  )?
( ( DeleteClause InsertClause? ) | InsertClause )
( USING ( NAMED )? IRIref )*
WHERE GroupGraphPattern

Unlike other forms of EBNF where square brackets denote optionality, here [] is used for blank nodes, as in SPARQL Query. | is used to denote alternatives, () is used for grouping terms, ? indicates 0 or 1 occurrence of a term, * indicates 0 or more occurrences, and + indicates 1 or more occurrences.

BOLD indicates language keywords. Italics indicate syntactic items defined in the SPARQL 1.1 Query Grammar, where we occasionally refer to productions by links. Unitalicized text indicates a local term that will have a more complex (and exact) definition in the formal grammar.

Example update requests are shown as follows:

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

Data is shown in Turtle syntax as follows:

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/books/> .
:book0  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 - An action to be performed that results in the modification of data in a Graph Store expressible as a single command, e.g. INSERT or DELETE.
• Request - A sequence of zero or more operations that is 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:

• QuadPattern - A syntactic construct that refers to a set of triple patterns, similar to ConstructTriples, but potentially involving the GRAPH keyword to indicate that a set of triples is to be inserted into/deleted from a named graph.
• QuadData - A QuadPattern without variables.
• GroupGraphPattern - A syntactic construct for referring to a set of triples, possibly with complex constraints.

3.1.1 INSERT DATA

The INSERT DATA operation adds some triples, given inline in the request, into the Graph Store:

INSERT DATA  QuadData 

where QuadData are formed by TriplesTemplates, i.e., sets of triple patterns, optionally wrapped into a GRAPH block.

 ( GRAPH  VarOrIri )? { TriplesTemplate? }

Variables in QuadDatas are disallowed in INSERT DATA requests (see Notes 8 in the grammar). That is, the INSERT DATA statement only allows to insert ground triples. Blank nodes in QuadDatas are assumed to be disjoint from the blank nodes in the Graph Store, i.e., will be inserted with "fresh" blank nodes.

If no graph is described in the QuadData, then the default graph is presumed. If data is inserted into a graph that does not exist in the Graph Store, it SHOULD be created (there may be implementations providing an update service over a fixed set of graphs which in such case MUST return with failure for update requests that insert data into an unallowed graph).

Note that a triple MAY be considered to be "processed" with no action if that triple already exists in the graph. Further, note that

INSERT DATA { GRAPH <g> {} } ...

does not create <g>. If a user intends to just create a graph, then the graph management operations (CREATE/LOAD) may be used prior to any insertion operations.

Example 1: 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/book1> 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/book1> ns:price 42 .

Data after:

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

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

Example 2:

This SPARQL 1.1 Update request adds a triple to provide the price of a book. As opposed to the previous example, which affected the default graph, the requested change happens in the named graph identified by the IRI http://example/bookStore.

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ns: <http://example.org/ns#>
INSERT DATA
{ GRAPH <http://example/bookStore> { <http://example/book1>  ns:price  42 } }

Data before:

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

Data after:

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

3.1.2 DELETE DATA

The DELETE DATA operation removes some triples, given inline in the request, if the respective graphs in the Graph Store contain those:

DELETE DATA  QuadData 

QuadData denotes triples to be removed and is as described in INSERT DATA, with the difference that in a DELETE DATA operation neither variables nor blank nodes are allowed (see Notes 8+9 in the grammar).

As with INSERT DATA, DELETE DATA is meant for deletion of ground triples data which is why QuadData that contains variables or blank nodes is disallowed in DELETE DATA operations. The DELETE/INSERT operation can be used to remove triples containing blank nodes.

Note that the deletion of non-existing triples has no effect, i.e., triples in the QuadData that did not exist in the Graph Store are ignored. Blank nodes are not permitted in the QuadData, as these do not match any existing data.

Example 3: Removing triples from a graph

This request 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/book2> 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/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> 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/book2> ns:price 42 .

Example 4:

This SPARQL 1.1 Update request consists of two operations, including a triple to be deleted and a triple to be added (used here to correct a book title). As opposed to the previous example, which affected the default graph, the requested change happens in the named graph identified by the IRI http://example/bookStore.

PREFIX dc: <http://purl.org/dc/elements/1.1/>
DELETE DATA
{ GRAPH <http://example/bookStore> { <http://example/book1>  dc:title  "Fundamentals of Compiler Desing" } } ;

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

Data before:

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

Data after:

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

3.1.3 DELETE/INSERT

The DELETE/INSERT operation can be used to remove or add triples from/to the Graph Store based on bindings for a query pattern specified in a WHERE clause:

( WITH IRIref )?
( ( DeleteClause InsertClause? ) | InsertClause )
( USING ( NAMED )? IRIref )*
WHERE GroupGraphPattern

The DeleteClause and InsertClause forms can be broken down as follows:

DeleteClause ::= DELETE  QuadPattern 
InsertClause ::= INSERT  QuadPattern 

This operation identifies data with the WHERE clause, which will be used to compute solution sequences of bindings for a set of variables. The bindings for each solution are then substituted into the DELETE template to remove triples, and then in the INSERT template to create new triples. If any solution produces a triple containing an unbound variable or an illegal RDF construct, such as a literal in a subject or predicate position, then that triple is not included when processing the operation: INSERT will not instantiate new data in the output graph, and DELETE will not remove anything. The graphs used for computing a solution sequence may be different to the graphs modified with the DELETE and INSERT templates.

The WITH clause defines the graph that will be modified or matched against for any of the subsequent elements (in DELETE, INSERT, or WHERE clauses) if they do not specify a graph explicitly. If not provided, then the default graph of the Graph Store (or an explicitly declared dataset in the WHERE clause) will be assumed. That is, a WITH clause may be viewed as syntactic sugar for wrapping both the QuadPatterns in subsequent DELETE and INSERT clauses, and likewise the GroupGraphPattern in the subsequent WHERE clause into GRAPH patterns. This can be used to avoid refering to the same graph multiple times in a single operation.

Following the optional WITH clause are the INSERT and/or DELETE clauses. 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.

If the DELETE clause is omitted, then the operation only inserts data (see INSERT). If the INSERT clause is omitted, then the operation only removes data (see DELETE). The grammar does not permit both DELETE and INSERT to be omitted in the same operation.

The USING and USING NAMED clauses affect the RDF Dataset used while evaluating the WHERE clause. This describes a dataset in the same way as FROM and FROM NAMED clauses describe RDF Datasets in the SPARQL 1.1 Query Language. The keyword USING instead of FROM in update requests is to avoid possible ambiguities which could arise from writing "DELETE FROM". That is, the GroupGraphPattern in the WHERE clause will be matched against the dataset described by explicit USING or USING NAMED clauses, if specified, and against the Graph Store otherwise.

The WITH clause provides a convenience for when an operation primarily refers to a single graph. If a graph name is specified in a WITH clause, then - for the purposes of evaluating the WHERE clause - this will define an RDF Dataset containing a default graph with the specified name, but only in the absence of USING or USING NAMED clauses. In the presence of one or more graphs referred to in USING clauses and/or USING NAMED clauses, the WITH clause will be ignored while evaluating the WHERE clause.

The GroupGraphPattern in the WHERE clause is evaluated as in a SPARQL query "SELECT * WHERE GroupGraphPattern" and all the solution bindings are applied to the preceding DELETE and INSERT templates for defining the triples to be deleted from or inserted into the Graph Store.

Again, QuadPatterns are formed by TriplesTemplates, i.e., sets of triple patterns, optionally wrapped into a GRAPH block, where the GRAPH clause indicates the named graph in the Graph Store to be updated; on any TripleTemplates without a GRAPH clause, the INSERT or DELETE clauses applies to the graph specified by the WITH clause, or the default graph of the Graph Store if no WITH clause is present.

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

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

is considered equivalent to:

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

Note that explicit GRAPH clauses override a WITH clause. WITH provides a fallback to specify a graph (different from the default graph) to use when one is not explicitly stipulated via GRAPH.

Deleting triples that are not present, or from a graph that is not present will have no effect and will result in success. Blank nodes are prohibited in a DELETE template, since using a new blank node in a DELETE template would lead to nothing being deleted, as a new blank node cannot match anything in the Graph Store. It should be noted that this restriction is not in the EBNF for the DeleteClause itself, but made explicit in Note 9 to the grammar.

If an operation tries to insert into a graph that does not exist, then that graph SHOULD be created; again, there may be implementations providing an update service over a fixed set of graphs which in such case MUST return with failure for update requests that would create an unallowed graph. If no data is to be inserted, then no graph will be created. Particularly, note that

INSERT ... { GRAPH <g> {} } ...

does not create <g>. If a user 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.

Blank nodes that appear in an INSERT clause operate similarly to blank nodes in the template of a CONSTRUCT query, i.e., they are re-instantiated for any solution of the WHERE clause; refer to Templates with Blank Nodes in SPARQL Query 1.1 and to the formal semantics of DELETE/INSERT below for details. Blank nodes in the WHERE clause match data in the same way as for any SPARQL Query.

Example 5:

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

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

WITH <http://example/addresses>
DELETE { ?person foaf:givenName 'Bill' }
INSERT { ?person foaf:givenName 'William' }
WHERE
  { ?person foaf:givenName 'Bill'
  } 

Data before:

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

<http://example/president25> foaf:givenName "Bill" .
<http://example/president25> foaf:familyName "McKinley" .
<http://example/president27> foaf:givenName "Bill" .
<http://example/president27> foaf:familyName "Taft" .
<http://example/president42> foaf:givenName "Bill" .
<http://example/president42> foaf:familyName "Clinton" .

Data after:

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

<http://example/president25> foaf:givenName "William" .
<http://example/president25> foaf:familyName "McKinley" .
<http://example/president27> foaf:givenName "William" .
<http://example/president27> foaf:familyName "Taft" .
<http://example/president42> foaf:givenName "William" .
<http://example/president42> foaf:familyName "Clinton" .

( WITH  IRIref )?
DELETE  QuadPattern 
( USING ( NAMED )? IRIref )*
WHERE GroupGraphPattern

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

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

<http://example/book1> dc:title "Principles of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

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

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

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

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

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

WITH <http://example/addresses>
DELETE { ?person ?property ?value } 
WHERE { ?person ?property ?value ; foaf:givenName 'Fred' } 
                       

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

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

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

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

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

( WITH  IRIref )?
INSERT  QuadPattern 
( USING ( NAMED )?  IRIref )*
WHERE GroupGraphPattern

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

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

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

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

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

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

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

# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

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

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

INSERT 
  { GRAPH <http://example/addresses>
    {
      ?person  foaf:name  ?name .
      ?person  foaf:mbox  ?email
    } }
WHERE
  { GRAPH  <http://example/people>
    {
      ?person  foaf:name  ?name .
      OPTIONAL { ?person  foaf:mbox  ?email }
    } }

# Graph: http://example/people
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf:  >http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

_:a  rdf:type        foaf:Person .
_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@example.com> .

_:b  rdf:type        foaf:Person .
_:b  foaf:name       "Bob" .

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

# Graph: http://example/people
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf:  >http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

_:a  rdf:type        foaf:Person .
_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@example.com> .

_:b  rdf:type        foaf:Person .
_:b  foaf:name       "Bob" .

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

_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@example.com> .

_:b  foaf:name       "Bob" .

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

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

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1996-01-01T00:00:00-02:00"^^xsd:dateTime .
<http://example/book1> a dcmitype:PhysicalObject .

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

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

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

# 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 "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/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1996-01-01T00:00:00-02:00"^^xsd:dateTime .
<http://example/book1> a dcmitype:PhysicalObject .

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

DELETE WHERE  QuadPattern 

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

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

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

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

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

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

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

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

DELETE WHERE {
  GRAPH <http://example.com/names> {
    ?person foaf:givenName 'Fred' ;
            ?property1 ?value1
  }
  GRAPH <http://example.com/addresses> {
    ?person ?property2 ?value2
  }
}

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

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

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

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

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

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

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

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

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

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

3.1.4 LOAD

The LOAD operation reads an RDF document from a IRI and inserts its triples into the specified graph in the Graph Store. The specified destination graph SHOULD be created if required; again, implementations providing an update service over a fixed set of graphs MUST return with failure for a request that would create a disallowed graph. If the destination graph already exists, then no data in that graph will be removed.

LOAD ( SILENT )? IRIref_from ( INTO GRAPH IRIref_to )?

IRIref_from specifies the IRI of a document such that a store will be able to identify, locate and read the document. The most common form will be URLs with the http IRI schemes. Once the document has been read, the resulting triples will be inserted into the destination graph named by the IRI referred to by IRIref_to.

If no destination graph IRI (IRIref_to) 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 (as opposed to the empty graph being retrieved) from the IRI denoted by IRIref_from, or in case the retrieval method returns an error (such as, for instance an HTTP error code), the SPARQL 1.1 Update service SHOULD return failure and the status of the Graph Store SHOULD remain in the same status as prior to the request; in case the keyword SILENT is present, however, the operation will still return success and the status of the Graph Store is not specified by the present document: implementations may create the destination graph or not and partially load data, in case of a transmission error where partial data has been received (which itself may be legal RDF).

3.1.5 CLEAR

The CLEAR operation removes all the triples in the specified graph(s) in the Graph Store.

CLEAR  ( SILENT )? (GRAPH IRIref | DEFAULT | NAMED | ALL )

Here, the DEFAULT keyword is used to remove all triples in the default graph of the Graph Store, the NAMED keyword is used to remove all triples in all named graphs of the Graph Store and the ALL keyword is used to remove all triples in all graphs of the Graph Store. The GRAPH keyword is used to remove all triples from a graph denoted by IRIref. 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 IRIref 

in principle has the same effect as:

# Remove all triples from the graph named with the IRI denoted by IRIref.
DELETE { GRAPH IRIref { ?s ?p ?o } } WHERE { GRAPH IRIref { ?s ?p ?o } }

If the store records the existence of empty graphs, then the SPARQL 1.1 Update service, by default, SHOULD 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.1 CREATE

This operation creates a graph in the Graph Store:

CREATE ( SILENT )? GRAPH IRIref

For stores that record empty graphs, this will create a new empty graph in the store with a name specified by the IRI. If the graph already exists, then a failure SHOULD be returned, except when the SILENT keyword is used; in either case, the contents of already existing graphs remain unchanged. If the graph may not be created, then a failure MUST be returned, except when the SILENT keyword is used.

Stores that do not record empty named graphs will always return success on creation of a non-existing graph.

3.2.2 DROP

DROP  ( SILENT )? (GRAPH IRIref | DEFAULT | NAMED | ALL )

The DROP operation removes the specified graph(s) from the Graph Store. The GRAPH keyword is used to remove a graph denoted by IRIref, 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., resetting the store. After successful completion of this operation, the specified graphs are 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, i.e., DROP DEFAULT is equivalent to CLEAR DEFAULT.

If the store records the existence of empty graphs, then the SPARQL 1.1 Update service, by default, SHOULD 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.

3.2.3 COPY

The COPY operation is a shortcut for inserting all data from an input graph into a destination graph. Data from the input graph is not affected, but data from the destination graph, if any, is removed before insertion.

COPY ( SILENT )? ( ( GRAPH )? IRIref_from | DEFAULT) TO ( ( GRAPH )? IRIref_to | DEFAULT )

is similar in operation to:

DROP SILENT (GRAPH IRIref_to | DEFAULT);
      INSERT { ( GRAPH IRIref_to )? { ?s ?p ?o } } WHERE { ( GRAPH IRIref_from )? { ?s ?p ?o } }

The difference between COPY and the DROP/INSERT combination is that if COPY is used to copy a graph onto itself then no operation will be performed and the data will be left as it was. Using DROP/INSERT in this situation would result in an empty graph.

If the destination graph does not exist, it will be created. By default, the service MAY return failure if the input graph does not exist. If SILENT is present, the result of the operation will always be success.

Example 13:

This example request copies all statements from the default graph to a named graph:

COPY DEFAULT TO <http://example.org/named>

Data before:

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

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

# Graph http://example.org/named
<http://example/fred> a foaf:Person .
<http://example/fred> foaf:givenName "Fred" .

Data after:

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

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

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

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

Note that the original content in http://example.org/named is lost by a COPY operation.

3.2.4 MOVE

The MOVE operation is a shortcut for moving all data from an input graph into a destination graph. The input graph is removed after insertion and data from the destination graph, if any, is removed before insertion.

MOVE (SILENT)? ( ( GRAPH )? IRIref_from | DEFAULT) TO ( ( GRAPH )? IRIref_to | DEFAULT)

is similar in operation to:

DROP SILENT (GRAPH IRIref_to | DEFAULT);
      INSERT { ( GRAPH IRIref_to )? { ?s ?p ?o } } WHERE { ( GRAPH IRIref_from )? { ?s ?p ?o } };
DROP ( GRAPH IRIref_from | DEFAULT)

The difference between MOVE and the DROP/INSERT/DROP combination is that if MOVE is used to move a graph onto itself then no operation will be performed and the data will be left as it was. Using DROP/INSERT/DROP in this situation would result in the graph being removed.

If the destination graph does not exist, it will be created. By default, the service MAY return failure if the input graph does not exist. If SILENT is present, the result of the operation will always be success.

Example 14:

This example request moves all statements from the default graph into a named graph:

MOVE DEFAULT TO <http://example.org/named>

Data before:

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

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

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

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

Data after:

# Default graph

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

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

Note that the original content in http://example.org/named is lost by a MOVE operation.

3.2.5 ADD

The ADD operation is a shortcut for inserting all data from an input graph into a destination graph. Data from the input graph is not affected, and initial data from the destination graph, if any, is kept intact.

ADD ( SILENT )? ( ( GRAPH )? IRIref_from | DEFAULT) TO ( ( GRAPH )? IRIref_to | DEFAULT)

is equivalent to:

INSERT { ( GRAPH IRIref_to )? { ?s ?p ?o } } WHERE { ( GRAPH IRIref_from )? { ?s ?p ?o } }

If the destination graph does not exist, it will be created. By default, the service MAY return failure if the input graph does not exist. If SILENT is present, the result of the operation will always be success.

Example 15:

This example request adds all statements from the default graph to a named graph:

ADD DEFAULT TO <http://example.org/named>

Data before:

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

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

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

<http://example/fred> a foaf:Person .

Data after:

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

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

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

<http://example/fred> a foaf:Person .

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

4.1.1 Graph Store

4.1.2 Abstract Update Operation

We will define the semantics of each concrete update operation in terms of concrete instances of this abstract update operation definition.

4.2.1 Dataset-UNION

This basic operation creates the union of two RDF Datasets.

4.2.2 Dataset-DIFF

This operation removes the triples of a given dataset from another dataset.

4.2.3 Dataset( QuadPattern, μ, DS, GS )

The following auxiliary function constructs an RDF Dataset from a QuadPattern, given a solution mapping and an RDF Dataset.

The function sk_μ guarantees that "fresh" blank nodes in the QuadPattern are re-instantiated "per solution" μ (analogous to the treatment of blank nodes in CONSTRUCT templates in the SPARQL1.1 Query Language); cf. also the respective remarks on scoping of blank nodes within requests in the SPARQL grammar.

4.2.4 Dataset( QuadPattern, P, DS, GS )

The following auxiliary function constructs an RDF Dataset from a QuadPattern, given a graph pattern and an RDF Dataset.

The definition of eval'() guarantees that co-referent blank nodes in DS are not "lost" during pattern evaluation, cf. Treatment of Blank Nodes in SPARQL1.1 Query. The latter is necessary to ensure that blank nodes in DS can be matched against existing blank nodes in GS to remove/add triples. In order to illustrate matching against existing blank nodes in the Graph Store, the following update request removes all triples with blank node as subject.

DELETE { ?S ?P ?O . } WHERE { ?S ?P ?O . FILTER ( isBlank(?S)) } 

Data before:

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

_:b a foaf:Person .
:s  a foaf:Person .

Data after:

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

:s  a foaf:Person .

4.3.1 Insert Data Operation

4.3.2 Delete Data Operation

4.3.3 Delete Insert Operation

4.3.4 Load Operation

4.3.5 Clear Operation

4.4.1 Create Operation

4.4.2 Drop Operation