QLever missing features or unexpected behavior

[hannahbast]

Whenever you encounter a query that you think should work (according to the SPARQL 1.1 standard) but throws an error message or gives an unexpected result, please post it here. Please check whether a similar query has already been posted before.

I will now move various queries from other issues here, so that we don't have one issue per query (which doesn't really help).

[hannahbast]

The SERVICE keyword is not yet supported [reported by @WolfgangFahl on 26.02.2022]:

https://qlever.cs.uni-freiburg.de/wikidata/QhTtmx

[hannahbast]

Square brackets are not yet supported [reported by @dpriskorn on 25.02.2022]:

https://qlever.cs.uni-freiburg.de/wikidata/dtZ84t

[hannahbast]

Minor syntax features not yet supported [reported by @WolfgangFahl on 19.02.2022]:

https://qlever.cs.uni-freiburg.de/wikidata/BGoE0M

Variant of the query that works: https://qlever.cs.uni-freiburg.de/wikidata/VgHqGB

[hannahbast]

Currently, only GET queries are supported, not POST [reported by @WolfgangFahl on 19.02.2022]:

This is easy to fix and on our list.

[hannahbast]

String functions are not yet supported in QLever [reported by @dpriskorn on 28.01.2022]:

https://qlever.cs.uni-freiburg.de/wikidata/EnB513

NOTE: The code for supporting functions in SPARQL expressions is all there. It's just a matter of adding more functions.

[hannahbast]

String functions not yet implemented [reported by @WolfgangFahl on 28.01.2022]:

https://qlever.cs.uni-freiburg.de/wikidata/0fidpY

The following equivalent query works: https://qlever.cs.uni-freiburg.de/wikidata/m49coC

[hannahbast]

Basic ?s ?p ?o query does not work yet in QLever [reported by @balhoff on 10.12.2021]:

https://qlever.cs.uni-freiburg.de/wikidata/VSpbRD

NOTE: This is easy to implement and is on our list

[jeremiahpslewis]

Quick question here, it's hard as a user to see which features are not currently supported if they are all in a single issue. What about using a query label to group all of these issues, but having separate issues for each failed query 'feature'?

[hannahbast]

String functions URI and CONCAT not yet supported [reported by @dpriskorn on 15.10.2022]:

https://qlever.cs.uni-freiburg.de/wikidata/5sDHUw

This variant of the query works: https://qlever.cs.uni-freiburg.de/wikidata/aIbGvo

[WolfgangFahl]

@hannahbast #607 shows how the sample queries can be tested with different endpoints.

[hannahbast]

FILTER with arbitrary expressions not yet supported [reported by @graue70 on 03.09.2021]:

https://qlever.cs.uni-freiburg.de/wikidata/Zd77YE

NOTE: The code for supporting arbitrary expressions is in place in the meantime, we "only" need to add this feature

[hannahbast]

Quick question here, it's hard as a user to see which features are not currently supported if they are all in a single issue. What about using a query label to group all of these issues, but having separate issues for each failed query 'feature'?

@jeremiahpslewis You are completely right and this issue is not for having a good overview, it's just to give people a chance to add a new query if they encounter one without opening a new issue every time. Having dozens of issues for things which are already on our list is not really helpful.

The solution I propose is that I add a page on the Wiki with a list of the features currently not supported (together with an estimate of when they will be supported and how hard it is).

[dpriskorn]

Do you accept pull requests? What would be a good first issue? 😀

[WolfgangFahl]

I have added more details to #607 and suggest to use named queries for continuous integration. IMHO it would be good to add the name of the query as comment e.g.

sparqlquery -qp wikidata.yaml --showQuery -qn HumansWithLibrisEntryAndImageAndMap 

named query HumansWithLibrisEntryAndImageAndMap

# humans with images and maps in swedish national library
# 53142 results in 20.6 seconds on Wikidata Query Service
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wikibase: <http://wikiba.se/ontology#>
SELECT ?item ?librisuri ?coord (sample(?img) AS ?image) (sample(?map) AS ?map) WHERE {
  # humans with a Libris-URI (swedish national library) and a known birthplace
  ?item wdt:P5587 ?librisid;
        wdt:P31 wd:Q5;
        wdt:P19 ?birthplace.
  # birthplace coordinates
  ?birthplace wdt:P625 ?coord.
  # image of the subject
  OPTIONAL {?item wdt:P18 ?img}.
  # map of the subject
  OPTIONAL {?item wdt:P242 ?map}.
  BIND(URI(CONCAT("https://libris.kb.se/katalogisering/",?librisid)) AS ?librisuri)
}
group by ?item ?librisuri ?coord

[WolfgangFahl]

@hannahbast Having dozens of issues for things which are already on our list is not really helpful. There is a tradeoff here. Personally i'd prefer an issue per case because referencing is much easier. Adding labels to the issues would probably help and then there is of course the "duplicate of ..." which makes sure there will be a core issue for each case.

[joka921]

Do you accept pull requests? What would be a good first issue? grinning Of course, see my email from yesterday.

[hannahbast]

@WolfgangFahl I don't think it make sense to have an issue for every minor feature that is missing at this point. Especially since the missing features come in large groups and then a single PR might address many issues at the same time. I don't think it's the best investment of our time to clean up the issues :-)

When we are approaching full SPARQL 1.1 support, this certainly does make sense. Then we can also react quickly: Issue -> PR -> solved. Right now, we can just repeat ourselves and says: yes we know, will be implemented soon, please give us some more time

[WolfgangFahl]

https://qlever.cs.uni-freiburg.de/wikidata/XGc3nb

PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
# Event / Proceedings pairs
SELECT ?event ?eventLabel ?proceedings ?proceedingsLabel ?ppn
WHERE {
  ?event wdt:P31 wd:Q2020153;
  # is proceedings from
  ^wdt:P4745 ?proceeding .
  #OPTIONAL {
  # ?proceedings wdt:P6721 ?ppn
  #}
  ?proceedings rdfs:label ?proceedingsLabel.
  filter(lang(?proceedingsLabel) = "en").
}

Exception: BAD QUERY (Could not find a suitable execution tree. Likely cause: Queries that require joins of the full index with itself are not supported at the moment.; in ../src/engine/QueryPlanner.cpp, line 2325, function std::vector > QueryPlanner::fillDpTab(const QueryPlanner::TripleGraph&, const std::vector&, const std::vector >&))

The error messages is IMHO not helpful .. it's just a typing error

https://qlever.cs.uni-freiburg.de/wikidata/3ZaksA

[hannahbast]

@WolfgangFahl I agree that the error message poorly describes what it should describe. What is should describe is that the query has two parts which are not connected. That, however, is indeed the problem with your example query. Here is a simpler query which has that problem due to a typo. I don't think, it's the task of a SPARQL engine to guess that the two independent query parts are due to a typo. It's an unfortunate property of SPARQL that if you mistype a variable name, you frequently get into this situation. Autocompletion helps to avoid that.

PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT ?subject WHERE {
  ?subject wdt:P31 wd:Q5 .
  ?sujbect wdt:P31 wd:Q159979 
}

[WolfgangFahl]

PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?count (COUNT(?count) AS ?frequency) WHERE {
# Count all human(Q5) https://www.wikidata.org/wiki/Q5 items
# with the given date of birth(P569) https://www.wikidata.org/wiki/Property:P569 
SELECT ?item ?itemLabel (COUNT (?value) AS ?count)
WHERE
{
  # instance of human
  ?item wdt:P31 wd:Q5.
  ?item wdt:P106 wd:Q82594.
  ?item rdfs:label ?itemLabel.
  filter (lang(?itemLabel) = "en").
  # date of birth
  ?item wdt:P569 ?value.
} GROUP by ?item ?itemLabel
}
GROUP BY ?count
ORDER BY DESC (?frequency)

https://qlever.cs.uni-freiburg.de/wikidata/IlDxae

Exception: ParseException, cause: Expected a token of type IRI but got a token of type KEYWORD (select) in the input at pos 153 : SELECT ?item ?itemLabel (COUNT (?value) AS ?count) WHERE { # instance of human ?item wdt:P31 wd:Q5. ?item wdt:P106 wd:Q82594. ?item rdfs:label ?itemLabel. filter (lang(?itemLabel) = "en"). # date of birth ?item wdt:P569 ?value. } GROUP by ?it

[hannahbast]

@WolfgangFahl QLever currently requires { ... } around subqueries. That is, the following equivalent query works: https://qlever.cs.uni-freiburg.de/wikidata/9DIJOj

Background information: QLever already uses a proper parser generator (ANTLR) for a part of its parsing (in particular, the SPARQL expressions). It's not yet used for parsing the whole SPARQL query. That explains many of these small inconsistencies. It will be solved soon.

[WolfgangFahl]

@hannahbast thx for the hint. I am currently working a tool that analyses "how tabular" a query based on an item and a list of properties is. This analysis might need some SPARQL features such as GROUP_CONCAT or workarounds for these.

The double curly braces issues is solvable with a workaround. The next issue is:

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
# get the label for the given item
SELECT ?itemLabel
WHERE
{
  VALUES (?item) {
    (wd:Q2020153)
  }
  ?item rdfs:label ?itemLabel.
  #filter (lang(?itemLabel) = "en").
}

which does not work with or without filter. see https://qlever.cs.uni-freiburg.de/wikidata/RK1eyG

while try it! works

[hannahbast]

@WolfgangFahl Just omit the two (...) in the VALUES clause and it works: https://qlever.cs.uni-freiburg.de/wikidata/7UCU23

[tuukka]

Is there a way to emulate EXISTS and BOUND which both seem to be unimplemented?

EDIT: I found !ASK but cannot use it in a FILTER: Exception: ParseException, cause: ! is not a valid left hand side for a filter. EDIT2: boolean literals don't seem to be implemented as false = ASK ... results in Unexpected input: false = ASK ... EDIT3: COALESCE also unimplemented.

[hannahbast]

@tuukka Do you have an example query? We are currently still working on full expression support. The basic machinery is in place (that was the hard part of the work), but not all functions and operators are implemented yet.

@joka921 Can you briefly comment on EXISTS and BOUND. Are they particularly easy or do you see any particular difficulty?

[tuukka]

@tuukka Do you have an example query? We are currently still working on full expression support. The basic machinery is in place (that was the hard part of the work), but not all functions and operators are implemented yet.

Here's an example query with EXISTS: Wikidata items that are humans but lack an article in English Wikipedia: https://qlever.cs.uni-freiburg.de/wikidata/58H7Sx

Same query using BOUND: https://qlever.cs.uni-freiburg.de/wikidata/9d0XXz

[hannahbast]

Ok, those are easy:

1. For the first query, you can replace FILTER NOT EXISTS by MINUS: https://qlever.cs.uni-freiburg.de/wikidata/ZuEUiK
2. For the second query, you can replace FILTER(!BOUND(?article)) by FILTER(?article > "<Z"): https://qlever.cs.uni-freiburg.de/wikidata/fPUSFt

Explanation @1: The two are often equivalent, except for some obscure queries involving OPTIONAL (not the case here). Explanation @2: The "null" value is large than all "real" values in QLever.

Note that both queries also work without LIMIT, whereas on https://query.wikidata.org they time out (like almost all queries with non-trivial constraints and without LIMIT).

[tuukka]

@hannahbast Thank you, I had completely missed MINUS! Now the query I originally wanted to write is working (although somewhat slow and threatens to run out of memory): Wikidata items that have many articles but not an English one: https://qlever.cs.uni-freiburg.de/wikidata/R5z27F

EDIT: If a guide for porting queries from WDQS does not exist yet, that might be a nice way to document the current differences?

[hannahbast]

EDIT: If a guide for porting queries from WDQS does not exist yet, that might be a nice way to document the current differences?

@tuukka @WolfgangFahl @joka921 I have started a Wiki page now: https://github.com/ad-freiburg/qlever/wiki/Current-deviations-from-the-SPARQL-1.1-standard

[WolfgangFahl]

in-clause for Filter is missing see https://qlever.cs.uni-freiburg.de/wikidata/ruLOCV