How does QLever handle GROUP_CONCAT?

[tholzheim]

From the definition of GroupConcat I would assume that the inputs of the function are converted to strings and the output is the concatenation of the strings to one string.

For example for the following query

SELECT (GROUP_CONCAT(?literal; separator=".") as ?literals)
WHERE{ 
    VALUES ?literal {"a" "b" "c"}
}

Try it with QLever or wikidata

I would assume the result "a.b.c" (order of strings not important) as stated by the definition. The wikidata wndpoint does return this result but QLever returns "a"."b"."c".

If a language tag is added e.g. @en the QLever result becomes "a"@en."b"@en."c"@en whereas the wikidata endpoint returns a.b.c

Try it with QLever or wikidata

Since GROUP_CONCAT is specified as string concatenation I would expect that the quotes of a single value are not included in the concat result so that the concatenation result only contains the values separated by the defined separator.

[joka921]

Hi,
QLever currently uses the full form "stringContent"@langtag for all kinds of expressions. We are aware of this issue, and I am aiming to fix this soon. Another thing that is not conforming to the SPARQL standard (the wikidata query service's behavior is correct here).
Another issue (actually the same one internally) is that <someIriref> is also considered as a string for these expressions, but actually it should not be a string, and STR(<someIriref>) should be someIriref.
As I am currently unifying the expressions in QLever I hope to fix those issues (which are annoying for ourselves too) soon.

[retog]

Good news: the issue with literals has meanwhile been fixed in QLever. However, its behaviour is still different from other SPARQL-implementations — e.g. the one used by Wikidata. Specifically, when an IRI appears in the list for GROUP_CONCAT, other implementations return the literal string value of the IRI (i.e. the result of STR(<...>)), but QLever returns an empty string.

For illustration: consider this query with an IRI in the list passed to GROUP_CONCAT:

PREFIX wd: <http://www.wikidata.org/entity/>
SELECT (GROUP_CONCAT(STR(?x); separator=", ") AS ?vals) WHERE {
  VALUES ?x { wd:Q42 "b" "c"}
}

• On Wikidata endpoint this returns: http://www.wikidata.org/entity/Q42, b, c
• On QLever result for ?vals is empty.

Things work as expected by explicitly calling STR:

PREFIX wd: <http://www.wikidata.org/entity/>
SELECT (GROUP_CONCAT(STR(?x); separator=", ") AS ?vals) WHERE {
  VALUES ?x { wd:Q42 "b" "c"}
}

[hannahbast]

@retog Your two queries look identical, did you mean to omit the STR in your first one?

[retog]

right, sorry.

[hannahbast]

@joka921 @RobinTF I just checked the reference engine, and there should indeed be an automatic conversion of IRIs to strings. This should be easy to fix, right?

$ cat one-triple.ttl 
@prefix ex: <http://example.org/> .
ex:s ex:p ex:o .
$ bin/sparql --engine ref --data one-triple.ttl --query <(echo 'PREFIX ex: <http://example.org/> SELECT (GROUP_CONCAT(?x; separator=", ") AS ?concat) WHERE { VALUES ?x { ex:a 42 } }')
------------------------------
| concat                     |
==============================
| "http://example.org/a, 42" |
------------------------------

[RobinTF]

@hannahbast As the folks from the SPARQL standard already pointed out, it's not a reference engine.
Regardless, group concat is defined recursively on regular concat, which only accepts string literals as arguments:
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#func-concat

[hannahbast]

@RobinTF I think you misunderstood. The engine behind https://sparql.org/query-validator.html is not a reference engine. But bin/sparql --engine ref is, at least that is my understanding and the name of the argument strongly implies it

And yes, you are right regarding CONCAT (and bin/sparql --engine ref agrees), but it's different for GROUP_CONCAT

[RobinTF]

The standard disagrees with you though:

Certain functions (e.g. REGEX, STRLEN, CONTAINS) take a string literal as an argument and accept a simple literal, a plain literal with language tag, or a literal with datatype xsd:string. They then act on the lexcial form of the literal.

The term string literal is used in the function descriptions for this. Use of any other RDF term will cause a call to the function to raise an error.

https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#func-strings

And CONCAT is defined as:

string literal CONCAT(string literal ltrl1 ... string literal ltrln)
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#func-concat

And GROUP_CONCAT() is defined on top of CONCAT.
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#defn_aggGroupConcat

[hannahbast]

@RobinTF Good point, I also don't see a hint in the standard why GROUP_CONCAT should do automatic string conversion. Not having a reliable implementation of the standard for these matters (not even sparql --engine ref) is really troubling

[retog]

Not doing string conversion would be one thing, but ignoring all values if just one of them is not a string goes further than that and seems to be at odds with the open world assumption.

[hannahbast]

@retog That is exactly what the standard demands: one argument is not a string literal, then the whole result is undefined. And other engines also do it that way for CONCAT, for example, https://w.wiki/GX32 (and Jena's sparql --engine ref does the same thing).

It's just that some systems do it differently for GROUP_CONCAT, although the standard very clearly defines GROUP_CONCAT via CONCAT