Autocomplete suggestion for language filtering leads to error

[graue70]

Take the following example:

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
SELECT WHERE {
  wd:Q231259 wdt:P40 ?child .
  ?child rdfs:label ?label .
  <CURSOR>
}

The suggested autocompletions contain FILTER langMatches(lang(?label), "en") ., which leads to a ParseException when the query is executed. The fix seems to be to replace the suggestion by FILTER (lang(?label) = "en") . (see ad-freiburg/qlever#336 for details).

As the latter is supposedly 'better anyway', it should be suggested in the autocompletion dropdown instead of the former.

[graue70]

The wiki seems to suggest that FILTER(LANG(?label) = "en") is preferred over FILTER (lang(?label) = "en") (note the missing space and the capitalization). If that's the case, the UI should suggest the preferred one. I will ask Hannah to comment. (I can't tag her directly.)

[hannahbast]

Yes, this should be fixed ASAP

@jbuerklin: Can you do that? It should be an easy fix. Just suggesting FILTER (lang(?... = "...")) instead of FILTER langMatches(lang(?...), "...")

And while we are at it, could there be an optional checkbox in the configuration, with the following functionality when checked: when the top suggestion from the backend for an object is a literal (e.g. "politician"@en), then for each of the "Filter languages" from the configuration (typically only one, say "en") add that language to the variable suggestion (e.g. "?label [en] .") and when selecting that suggestion, extend the query by that variable and the corresponding language filter (e.g. "?label . FILTER (lang(?label) = "en") . "

That would be awesome because that is a pretty frequent completion and it would save a lot of keystrokes. It shouldn't be configurable, however, as suggested.

If it's a problem to have the filter in the same line as the preceding triple, you can also put it in a separate line. But that way, queries become rather long rather quickly.

(Anyway, SPARQL doesn't really care about newlines while the current UI does, but that is a separate issue.)

[graue70]

Yes, this should be fixed ASAP

@jbuerklin: Can you do that? It should be an easy fix. Just suggesting FILTER (lang(?... = "...")) instead of FILTER langMatches(lang(?...), "...")

@hannahbast It was already fixed in the commit above my comment. My question to you is whether FILTER(LANG(?label) = "en") should be preferred over FILTER (lang(?label) = "en") (differing only by capitalization and one whitespace) because it is written that former way in the wiki.

The other topic should probably be a different issue. Especially because this one is already closed?

[hannahbast]

I am sorry for the confusion.

@space: I am not sure and it's used pretty inconsistently by others, too. My gut feeling has a slight preference for putting a space between the FILTER keyword and the open parenthesis. So let's go forward with that for now. I have changed the example queries on the Wiki page (referenced by Thomas above) accordingly.

@capitalization: Capitalization of keywords and function names seems to be the prevailing way. So let's go with LANG and not lang.

I will open an issue considering the other issue :-)

[jbuerklin]

Changed lang to LANG in 54aedff