QLever aims to support the full SPARQL 1.1 standard and is not far away from it anymore

Last year, we received funding to make QLever fully compliant with the SPARQL 1.1 standard. The deadline is 30.06.2025. Our goal is to not only implement the standard, but to do so in a way that maintains QLever outstanding efficiency. The vast majority of features is already implemented. Here is an overview over all the features, grouped according to the test suite https://www.w3.org/2009/sparql/docs/tests . Last updated on 20.02.2025.

TLDR: Most features are implemented, with still a few subtle deviations from the standard here and there; SPARQL 1.1 Update is implemented in its basic form but still work in progress; named graphs are implemented but are not yet efficient when a permutation sorted by G is required.

Feature group	What's missing if anything
Exists	all checks pass
Property paths	error for certain complex paths involving the empty path or negation
Construct	all check pass
Entailment	not yet implemented
Grouping	all checks pass [1]
Aggregates	all checks pass [1]
Service	variable endpoint not yet supported
Functions	still a few subtle deviations from the standard, some intended, some need fixing
Bind	all checks pass [1]
CSV & TSV	all checks pass
Cast	all checks pass [1]
JSON	all checks pass [1]
Delete-insert	Multiple updates in one request are not yet supported
Delete-data	two tests fail with assertion error
Drop	not yet implemented
Basic-update	some checks involving blank nodes fail
Update-silent	not yet implemented
Clear	not yet implemented
Delete	some checks involving WITH and USING fail
Add	not yet implemented
Copy	not yet implemented
Protocol	PUT not yet implemented + "SparqlJSON export is not supported for CONSTRUCT queries"
http-rdf-update	GraphStoreProtocol not yet implemented

[1] QLever currently represents all integers in at most 60 bits. It therefore never outputs integers as xsd:integer, but always as xsd:int. Most checks in the test suite involving integers expect xsd:integer.

The rest of this page was last updated in August 2024 (and is kept here for historical reference)

SPARQL 1.1 features that are not yet implemented, with a workaround or an estimate of when they will be implemented

Feature: QLever currently does not support named graphs (GRAPH, FROM, FROM NAMED). Plan: We are currently working on it, see PR #1337. Expected to be available by July.

Feature: QLever currently does not support SPARQL 1.1 Update operations. Plan: We are currently working on it. PR #916 implements a proof of concept that works with the QLever version at that time. Expected to be available by the summer.

Feature: Most built-in functions, as defined in Section 9.8 of the SPARQL standard, grammar rule [121], are implemented by now; see the last section below. Still missing are the more esoteric ones: BNODE, STRLANG, now, Plan: Let us know (by opening an issue) if you need one of the missing functions urgently. Or consider adding a PR, which implements it, yourself. You can use PR #1047, or one of the other PRs that implement a built-in function and are listed below, as a template. It's relatively easy and schematic.

Feature: QLever does not yet support EXISTS { subquery } or ASK { subquery }, which return false if the subquery is empty, and true otherwise. Plan: There is a workaround using UNION and COUNT, but it's rather clumsy and ugly. We should implement this very soon!

Feature: QLever does not yet support FILTER NOT EXISTS. Workaround: For most queries, this is exactly equivalent to MINUS. The subtle differences are explained in the SPARQL 1.1 standard. We will eventually implement it.

Feature: QLever does not yet support DESCRIBE. Workaround: This can be easily simulated using an ordinary SELECT query. For example, instead of DESCRIBE wd:Q42, one could write SELECT ?s ?p ?o WHERE { BIND(wd:Q42 AS ?s) ?s ?p ?o }. Note that the SPARQL standard does not dictate exactly which triples are returned to "describe" the entity. For example, one could also add triples that have the entity as their object.

Feature: QLever does not yet support ASK. Workaround: This can also be easily simulated using an ordinary SELECT query. For example, instead of ASK { ?subject wdt:P31 wd:Q5 . ?subject wdt:P31 wd:Q16521 } one can equivalently write SELECT (COUNT(*) > 0 AS ?exists) { ?subject wdt:P31 wd:Q5 . ?subject wdt:P31 wd:Q16521 }.

SPARQL 1.1 Features that used to be missing, but were added in the meantime

SOLVED BY PR #1366: Support for UUID/STRUUID

SOLVED BY PR #1382: Support for lang/langMatches

SOLVED BY PR #1386: Support for timezone

SOLVED BY PR #1342: Support for MD5, SHA1 etc..

SOLVED BY PR #1401: Support for IRI/URI

SOLVED BY PR #1359: Support for tz.

SOLVED BY PR #1344: Support for IN and NOT IN. Here is an example query.

SOLVED BY PR #1310: Unlimited support for new entities or literal in a query (for example, "this string was probably not in the input data"@en),

SOLVED by PR #1279: Support for everything involving [...] (blank nodes and blank node property lists) in a SPARQL query.

SOLVED by PR #1184: Add built-in functions isIRI, isBlank, isLiteral, isNumeric, bound.

SOLVED by PR #1128: Add built-in function ENCODE_FOR_URI.

SOLVED by PR #1116: Add built-in functions HOURS, MINUTES, and SECONDS.

SOLVED by PR #1057, PR #1060, PR #1065, PR #1070, PR #1074, PR #1085: Add builtin-functions SUBSTR, UCASE, LCASE, STRSTARTS, STRENDS, STRBEFORE, STRAFTER, CONTAINS, IF, COALESCE, CONCAT, and REPLACE.

SOLVED by PR #1047: Add math functions log, exp, sqrt, sin, cos, tan.

SOLVED by PR #793: Support the SERVICE clause. This required a variety of deeper changes, namely code for communicating with a remote server via HTTP or HTTPS (#823 and #900), as well as code for dealing with entities that are not contained in the vocabulary of the original index (#820, #822, #838, and #880). See the commit message of PR #793 for the restrictions.

SOLVED by PR #793: Implement the built-in functions STR, STRLEN, DAY, MONTH, YEAR, and RAND. Using these as templates, it will now be easy to implement more of them.

SOLVED by PR #790: Since this PR, the whole SPARQL query is parsed using ANTRL using the SPARQL grammer from the standard. That way, many idiosyncrasies of QLever's query parsing so far have disappeared.

SOLVED by PR #749: Parse according to the official SPARQL 1.1 grammar. In particular: allow { ... } around a group graph pattern (with the semantics that this part of a query is optimized independently) and don't require a dot before FILTER or OPTIONAL or MINUS. QLever's previous hand-written parser had all kinds of idiosyncrasies, which are all removed by this PR.

SOLVED BY PR #726: Use arbitrary expressions in FILTER or ORDER BY claueses. Before this PR, a workaround was to BIND the expression to a variable and then use this variable in the FILTER or ORDER BY.

SOLVED by PR #726: Allow to write true or 42 as a shorthand for "true"^^xsd:boolean or "42"^^xsd:int.

SOLVED by PR #669: Allow the shorthand a for rdf:type.

SOLVED by PR #657: Full support for not only GET requests, but also POST requests. In particular, support POST request with Content-type: application/sparql-query.