QLever aims to support the full SPARQL 1.1 standard and is not far away from it anymore. It makes sense to distinguish three groups of features:

1. SPARQL 1.1 features that are not yet implemented, but have an easy workaround
2. SPARQL 1.1 features that could be added in a day's work
3. SPARQL 1.1 features that require more work (days to weeks)

At the end of this section, we also list features that used to be in one of these groups, but have been implemented in the meantime_

SPARQL 1.1 features that are not yet implemented, but have an easy workaround

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.

Feature: QLever does not yet support the IN or NOT IN keyword inside a FILTER. Workaround: You can replace it with an equivalent VALUES clause. For example, instead of FILTER (?country_label IN ("Germany"@en, "France"@en, "Norway"@en)), write VALUES ?country_label { "Germany"@en "France"@en "Norway"@en }. Here is an example query.

Feature: QLever supports new entities or literal in a query (for example, "this string was probably not in the input data"@en) only to a limited extent. Workaround: See Issue #1242 for an explanation of the limitation and a workaround.

2. SPARQL 1.1 features that could be added in a day's work

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. There are still a few more esoteric ones missing, like UUID. Solution: 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.

3. SPARQL 1.1 features that require more work (days to weeks)

Feature: QLever currently does not support SPARQL 1.1 Update operations. Solution: PR #916 implements a proof of concept for SPARQL 1.1 Update that works with the QLever version at that time (June 2023). It remains to integrate this into our current master and test it extensively. It is on our short list for the next months.

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

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.