SPARQL compliance¶

What’s in this document?

SPARQL 1.1 Protocol for RDF
SPARQL 1.1 Query
SPARQL 1.1 Update
- Modification operations on RDF triples
- Operations for managing graphs
SPARQL 1.1 Federation
- Internal SPARQL Federation
- Federated query to a remote password-protected repository
SPARQL 1.1 Graph Store HTTP Protocol
SPARQL 1.1 non-conformance
- Deviations from SPARQL 1.1 tests

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 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 behavior. For full details, see the W3C SPARQL Update working group page.

Modification operations on 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. See more about it on this documentation’s SPARQL Federation page.

Internal SPARQL Federation ¶

In addition to the standard SPARQL 1.1 Federation to other SPARQL endpoints, GraphDB supports internal federation to other repositories in the same GraphDB instance. The internal SPARQL federation is used in almost the same way as the standard SPARQL federation over HTTP, but since this approach skips all HTTP communication overheads, it is more efficient. See more about it in the Internal SPARQL federation section of this documentation’s SPARQL Federation page.

Federated query to a remote password-protected repository ¶

You can also use federation to query a remote password-protected GraphDB repository and a SPARQL endpoint. See how in Federated query to a remote password-protected repository.

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 using the Graph Store HTTP Protocol are provided at:

<RDF4J_URL>/repositories/<repo_id>/rdf-graphs/service> (for indirectly referenced named graphs)

URL patterns ¶

<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 the supported RDF formats.
Content-Type: Must specify the encoding of any request data sent to a server. Relevant values are the MIME types of the 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.

Note

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

SPARQL 1.1 non-conformance ¶

While GraphDB mostly conforms to the SPARQL 1.1 standard, there are some deviations.

Conformant behavior	Implemented behavior	Reasoning
Any `FILTER` expressions inside a `UNION` should only see bindings created within their branch.	GraphDB allows `FILTER` expressions to evaluate variables that were bound in outer or sibling groups.	Intentional deviation. This behavior provides a more intuitive experience when writing queries where the same variable name is reused. It avoids surprises when `FILTER(?z = ...)` appears to “do nothing” because `?z` was re-bound in a sub-group. The issue can be easily avoided by using unique variable names in nested expressions.
If `SILENT` is used, the engine should ignore any errors coming from the service (such as the remote service not being available), and return local results.	When `SILENT` is used, GraphDB ignores the fact that the remote service is not available, but returns empty results instead of giving only the local data in the results.	Intentional deviation. When users are querying data from a remote service, they most likely need the data from that service specifically. Returning the local data can thus be misleading. Note This behavior can be circumvented by wrapping the service expression with `OPTIONAL` in order to fetch local data.
A `DELETE` that does not specify a graph should only delete data in the default graph.	When `DELETE` is used without specifying a graph, GraphDB deletes data from all graphs.	Unintentional deviation. However, since there are queries relying on this behavior, and it cannot be fixed in a way that makes queries backwards compatible, it has been intentionally left as is for the time being. Warning This will be addressed in a future major release of GraphDB (version 12.0 or later), making the behavior conform to SPARQL 1.1.

Conformant behavior

Implemented behavior

Reasoning

Any FILTER expressions inside a UNION should only see bindings created within their branch.

GraphDB allows FILTER expressions to evaluate variables that were bound in outer or sibling groups.

Intentional deviation. This behavior provides a more intuitive experience when writing queries where the same variable name is reused. It avoids surprises when FILTER(?z = ...) appears to “do nothing” because ?z was re-bound in a sub-group. The issue can be easily avoided by using unique variable names in nested expressions.

If SILENT is used, the engine should ignore any errors coming from the service (such as the remote service not being available), and return local results.

When SILENT is used, GraphDB ignores the fact that the remote service is not available, but returns empty results instead of giving only the local data in the results.

Intentional deviation. When users are querying data from a remote service, they most likely need the data from that service specifically. Returning the local data can thus be misleading.

Note

This behavior can be circumvented by wrapping the service expression with OPTIONAL in order to fetch local data.

A DELETE that does not specify a graph should only delete data in the default graph.

When DELETE is used without specifying a graph, GraphDB deletes data from all graphs.

Unintentional deviation. However, since there are queries relying on this behavior, and it cannot be fixed in a way that makes queries backwards compatible, it has been intentionally left as is for the time being.

Warning

This will be addressed in a future major release of GraphDB (version 12.0 or later), making the behavior conform to SPARQL 1.1.

Deviations from SPARQL 1.1 tests ¶

While the list above describes all known cases of non-conformance with SPARQL 1.1, GraphDB may also fail to conform to some of the official tests designed to evaluate conformance to the standard. However, for these tests it was determined that there were issues with the test itself, and not with the standard itself. Please note that the list below is not extensive, as there may be other cases of test failures despite GraphDB being compliant with the SPARQL 1.1 specifications.

syntax-service-01.rq: This test checks the handling of full IRIs without a scheme. GraphDB expects a full IRI, including the scheme (http:// or https://), which fails the test.

In the SPARQL standard there are mentions of a nonexistent section 5.1.4, “Default Base URI” which seems to have been deleted from the final specification. It was probably meant to describe how IRIs such as <g> should be treated with a BASE URI. The test is likely invalid as the official W3C SPARQL 1.1 standard does not explicitly specify how the scheme of such an IRI has to be handled.
bind07.rq: This test checks the behavior of a UNION of two BIND expressions so that each binds a different string to ?z. The test expects the UNION to be evaluated first in isolation, then the two BIND functions, producing two rows with different ?z values. In GraphDB, ?x :p ?y is joined with the entire UNION, then the two BIND expressions are applied afterwards, causing an unexpected presence of ?z and resulting in a different binding set than what the test expects.

Earlier versions of the SPARQL 1.1 standard had a section that specified how extension functions can be defined and used. That part of the specification was subsequently removed. The current specification does define evaluation order for joins — it just defines what solutions must be produced, and that variable bindings must be respected. This test does not match the current specification.