The Graph Store

A Graph Store is a mutable container of RDF graphs managed by a single service. Similar to an RDF Dataset operated on by the SPARQL 1.1 Query Language, a Graph Store contains one (unnamed) slot holding a default graph and zero or more named slots holding named graphs. Operations MAY specify graphs to be modified, or they MAY rely on a default graph for that operation. Unless overridden (for instance, by the SPARQL protocol), 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, a graph describing the named graphs, a representation of a union of other graphs, etc.

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. 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 can be used as a graph update language (as opposed to a Graph Store update language).

The information how a Graph Store is accessed is defined in the protocol and Graph Store protocol specs. A Graph Store is accessible by either an update service (cf. protocol) or via the Graph Store protocol (cf. Graph Store protocol). In either case the Graph Store is hidden behind the service, making it accessible via the URI of a SPARQL update service or via a URI that responds to the Graph Store protocol.

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.

Graph Store and SPARQL Query Services

A service (often referred to by the informal term SPARQL endpoint) that accepts and processes update requests is referred to as an update service. There is no presumption that the Graph Store managed by an update service 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.

SPARQL 1.1 Update Services

SPARQL 1.1 Update requests are sequences of operations.

Each request SHOULD be treated atomically by a SPARQL 1.1 Update service. The term 'atomically' means that a single request will result in either no effect or a complete effect, regardless of the number of operations that may be present in the request. Any resulting concurrency issues will be a matter for each implementation to consider according to its own architecture. In particular, using the SERVICE keyword in the WHERE clause of operations in an Update request will usually result in a loss of 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 independent entities. The behaviour of these services with respect to each other (such as automatic synchronization after updates) is implementation dependent.

Entailment and Consistency

If the store is capable of calculating entailed answers, see SPARQL 1.1 Entailment Regimes, then it is possible for update operations to interact with entailed data. In particular, a DELETE operation may attempt to remove entailed statements without actual effects.

After an update request is completed, a store that performs consistency checking with respect to a particular entailment regime on its graphs MAY check the new state of the Graph Store for consistency. If inconsistency is detected, such a store MAY return an error to the request.

Also of note is that some stores may be capable of performing entailments with respect to an ontology capable of higher level processing, such as RDFS or OWL. Updates may interact with these entailment regimes in these systems.