INSERT DATA

\n\n

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

**INSERT DATA ** *QuadData* \n

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

 ( GRAPH  VarOrIri )? { TriplesTemplate? }\n

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> {} } ...\n

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/>\nINSERT DATA\n{ \n  <http://example/book1> dc:title \"A new book\" ;\n                         dc:creator \"A.N.Other\" .\n}\n

Data before:

**# Default graph**\n@prefix dc: <http://purl.org/dc/elements/1.1/> .\n@prefix ns: <http://example.org/ns#> .\n\n<http://example/book1> ns:price 42 .\n

Data after:

**# Default graph**\n@prefix dc: <http://purl.org/dc/elements/1.1/> .\n@prefix ns: <http://example.org/ns#> .\n\n<http://example/book1> ns:price 42 .\n<http://example/book1> dc:title \"A new book\" .\n<http://example/book1> dc:creator \"A.N.Other\" .\n

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/>\nPREFIX ns: <http://example.org/ns#>\nINSERT DATA\n{ GRAPH <http://example/bookStore> { <http://example/book1>  ns:price  42 } }\n

Data before:

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

Data after:

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

"^^ ; ; . a ; . a ; ; ; ; ; ; ; ; ; ; ; "2023-07-10T16:14:39.647Z"^^ ; "Graph Update" ; ; ; . a ; "

CLEAR

\n\n

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

**CLEAR**  ( **SILENT** )? (**GRAPH** *[IRIref](../../../sparql11-query/grammar/#rIRIREF)* | **DEFAULT** | **NAMED** | **ALL** )\n

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.\n**CLEAR GRAPH** *IRIref* \n

in principle has the same effect as:

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

Note:

For services which form the default graph from the union of other graphs,

CLEAR DEFAULT may have further implications which we leave unspecified here.

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.

"^^ ; . a ; . a , ; "

Graph Update

\n\n

Graph update operations change existing graphs in the Graph Store but do not explicitly delete nor create them. Non-empty inserts into non-existing graphs will, however, implicitly create those graphs, i.e., an implementation fulfilling an update request SHOULD silently an automatically create graphs that do not exist before triples are inserted into them, and MUST return with failure if it fails to do so for any reason. (For example, the implementation may have insufficient resources, or an implementation may only provide an update service over a fixed set of graphs and the implicitly created graph is not within this fixed set). An implementation MAY remove graphs that are left empty after triples are removed from them.

If a graph is created implicitly by an update operation, then the behavior of the Graph Store MUST be functionally equivalent to its behavior if the graph had been created explicitly by a CREATE operation.

SPARQL 1.1 Update provides these graph update operations:

The INSERT DATA operation adds some triples, given inline in the request, into a graph. This SHOULD create the destination graph if it does not exist. If the graph does not exist and it can not be created for any reason, then a failure MUST be returned.
The DELETE DATA operation removes some triples, given inline in the request, if the respective graph contains those.
The fundamental pattern-based actions for graph updates are INSERT and DELETE (which can co-occur in a single DELETE/INSERT operation). These actions 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 substitute bindings into a template from a pattern. The DATA forms require concrete data (triple templates containing variables within DELETE DATA and INSERT DATA operations are disallowed and blank nodes are disallowed within DELETE DATA, see Notes 8+9 in the grammar). Having specific operations for concrete data 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 (one or more) graphs.

"^^ ; ; "Graph Update" . a ; "

LOAD

\n\n

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](../../../sparql11-query/grammar/#rIRIREF)* ( **INTO GRAPH** *[IRIref_to](../../../sparql11-query/grammar/#rIRIREF)* )?\n

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).

"^^ ; . a ; . a ; . a ; . a ; "

DELETE DATA

\n\n

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* \n

QuadData denotes triples to be removed and is as described in INSERT\nDATA, 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/>\n\nDELETE DATA\n{\n  <http://example/book2> dc:title \"David Copperfield\" ;\n                         dc:creator \"Edmund Wells\" .\n}\n

Data before:

**# Default graph**\n@prefix dc: <http://purl.org/dc/elements/1.1/> .\n@prefix ns: <http://example.org/ns#> .\n\n<http://example/book2> ns:price 42 .\n<http://example/book2> dc:title \"David Copperfield\" .\n<http://example/book2> dc:creator \"Edmund Wells\" .\n

Data after:

**# Default graph**\n@prefix dc: <http://purl.org/dc/elements/1.1/> .\n@prefix ns: <http://example.org/ns#> .\n\n<http://example/book2> ns:price 42 .\n

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/>\nDELETE DATA\n{ GRAPH <http://example/bookStore> { <http://example/book1>  dc:title  \"Fundamentals of Compiler Desing\" } } ;\n\nPREFIX dc: <http://purl.org/dc/elements/1.1/>\nINSERT DATA\n{ GRAPH <http://example/bookStore> { <http://example/book1>  dc:title  \"Fundamentals of Compiler Design\" } }\n

Data before:

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

Data after:

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

"^^ ; ; .