SPARQL compliance

GraphDB supports the following SPARQL specifications:

SPARQL 1.1 Protocol for RDF

SPARQL 1.1 Protocol for RDF defines the means for transmitting SPARQL queries to a SPARQL query processing service, and returning the query results to the entity that requested them.

SPARQL 1.1 Query

SPARQL 1.1 Query provides more powerful query constructions compared to SPARQL 1.0. It adds:

  • Aggregates;
  • Subqueries;
  • Negation;
  • Expressions in the SELECT clause;
  • Property Paths;
  • Assignment;
  • An expanded set of functions and operators.

SPARQL 1.1 Update

SPARQL 1.1 Update provides a means to change the state of the database using a query-like syntax. SPARQL Update has similarities to SQL INSERT INTO, UPDATE WHERE and DELETE FROM behaviour. For full details, see the W3C SPARQL Update working group page.

Modification operations on the RDF triples:

  • INSERT DATA {...} - inserts RDF statements;
  • DELETE DATA {...} - removes RDF statements;
  • DELETE {...} INSERT {...} WHERE {...} - for more complex modifications;
  • LOAD (SILENT) from_iri - loads an RDF document identified by from\_iri;
  • LOAD (SILENT) from_iri INTO GRAPH to_iri - loads an RDF document into the local graph called to\_iri;
  • CLEAR (SILENT) GRAPH iri - removes all triples from the graph identified by iri;
  • CLEAR (SILENT) DEFAULT - removes all triples from the default graph;
  • CLEAR (SILENT) NAMED - removes all triples from all named graphs;
  • CLEAR (SILENT) ALL - removes all triples from all graphs.

Operations for managing graphs:

  • CREATE - creates a new graph in stores that support empty graphs;
  • DROP - removes a graph and all of its contents;
  • COPY - modifies a graph to contain a copy of another;
  • MOVE - moves all of the data from one graph into another;
  • ADD - reproduces all data from one graph into another.

SPARQL 1.1 Federation

SPARQL 1.1 Federation provides extensions to the query syntax for executing distributed queries over any number of SPARQL endpoints. This feature is very powerful, and allows integration of RDF data from different sources using a single query.

For example, to discover DBpedia resources about people who have the same names as those stored in a local repository, use the following query:

SELECT ?dbpedia_id
   ?person a foaf:Person ;
           foaf:name ?name .
   SERVICE <> {
        ?dbpedia_id a dbpedia-owl:Person ;
                    foaf:name ?name .

It matches the first part against the local repository and for each person it finds, it checks the DBpedia SPARQL endpoint to see if a person with the same name exists and, if so, returns the ID.

Since RDF4J repositories are also SPARQL endpoints, it is possible to use the federation mechanism to do distributed querying over several repositories on a local server.

For example, imagine that you have two repositories - one called my_concepts with triples about concepts and another called my_labels, containing all label information.

To retrieve the corresponding label for each concept, you can execute the following query on the my_concepts repository:

SELECT ?id ?label
    ?id a ex:Concept .
    SERVICE <http://localhost:7200/repositories/my_labels> {
        ?id rdfs:label ?label.


Federation must be used with caution. First of all, to avoid doing excessive querying of remote (public) SPARQL endpoints, but also because it can lead to inefficient query patterns.

The following example finds resources in the second SPARQL endpoint, which have a similar rdfs:label to the rdfs:label of <> in the first SPARQL endpoint:

PREFIX rdfs:<>

SELECT ?endpoint2_id {
    SERVICE <>
        ?endpoint1_id rdfs:label ?l1 .
        FILTER( lang(?l1) = "en" )
    SERVICE <>
        ?endpoint2_id rdfs:label ?l2 .
        FILTER( str(?l2) = str(?l1) )
BINDINGS ?endpoint1_id
{ ( <> ) }

However, such a query is very inefficient, because no intermediate bindings are passed between endpoints. Instead, both subqueries execute independently, requiring the second subquery to return all X  rdfs:label Y statements that it stores. These are then joined locally to the (likely much smaller) results of the first subquery.

SPARQL 1.1 Graph Store HTTP Protocol

SPARQL 1.1 Graph Store HTTP Protocol provides a means for updating and fetching RDF graph content from a Graph Store over HTTP in the REST style.

URL patterns for this new functionality are provided at:

  • <RDF4J_URL>/repositories/<repo_id>/rdf-graphs/service> (for indirectly referenced named graphs);
  • <RDF4J_URL>/repositories/<repo_id>/rdf-graphs/<NAME> (for directly referenced named graphs).

Methods supported by these resources and their effects:

  • GET - fetches statements in the named graph from the repository in the requested format.
  • PUT - updates data in the named graph in the repository, replacing any existing data in the named graph with the supplied data. The data supplied with this request is expected to contain an RDF document in one of the supported RDF formats.
  • DELETE - deletes all data in the specified named graph in the repository.
  • POST - updates data in the named graph in the repository by adding the supplied data to any existing data in the named graph. The data supplied with this request is expected to contain an RDF document in one of the supported RDF formats.

Request headers:

  • Accept: Relevant values for GET requests are the MIME types of supported RDF formats.
  • Content-Type: Must specify the encoding of any request data sent to a server. Relevant values are the MIME types of supported RDF formats.

Supported parameters for requests on indirectly referenced named graphs:

  • graph (optional): specifies the URI of the named graph to be accessed.
  • default (optional): specifies that the default graph to be accessed. This parameter is expected to be present but to have no value.


Each request on an indirectly referenced graph needs to specify precisely one of the above parameters.