string functions produces unquoted string literals

[aindlq]

CONSTRUCT {
  <http://example.com> <http://example.com/label> ?value
} WHERE {
  BIND(CONCAT("A", "," , "B") AS ?value).
}

Getting turtle with curl:

curl 'https://qlever.cs.uni-freiburg.de/api/wikidata' -X POST -H 'Accept: text/turtle' -H 'Content-Type: application/x-www-form-urlencoded' --data-raw 'query=CONSTRUCT+%7B%0A++%3Chttp%3A%2F%2Fexample.com%3E+%3Chttp%3A%2F%2Fexample.com%2Flabel%3E+%3Fvalue%0A%7D+WHERE+%7B%0A++BIND(CONCAT(%22A%22%2C++%22%2C%22+%2C+%22B%22)++AS+%3Fvalue).%0A%7D&send=969'

Produces:

<http://example.com> <http://example.com/label> A,B .

But should be:

<http://example.com> <http://example.com/label> "A,B" .

[aindlq]

Workaround is to "add" quotes:

CONSTRUCT {
  <http://example.com> <http://example.com/label> ?value
} WHERE {
  BIND(CONCAT("\"",  "A", "," , "B",  "\"") AS ?value).
}

<http://example.com> <http://example.com/label> "A,B" .

[aindlq]

Apparently it is with all string functions, not only CONCAT. But all string functions, even STR.

CONSTRUCT {
  <http://example.com> <http://example.com/label> ?value
} WHERE {
  BIND(REPLACE("AA", "A",  "B") AS ?value).
}

<http://example.com> <http://example.com/label> BB .

STR

CONSTRUCT {
  <http://example.com> <http://example.com/label> ?a .
  <http://example.com> <http://example.com/label> ?b .
} WHERE {
  BIND("A" AS ?a) .
  BIND(STR(?a) AS ?b).
}

<http://example.com> <http://example.com/label> "A" .
<http://example.com> <http://example.com/label> A .

[aindlq]

Also looks like in some situations STR produce wrong string for URI.

CONSTRUCT {
  <http://example.com> <http://example.com/label> ?b .
} WHERE {
  BIND(STR(<http://example.com/A>) AS ?b).
}

<http://example.com> <http://example.com/label> <http://example.com/A> .

I believe the resulting value, even taking quotes bug into account, shouldn't have < and >.

[joka921]

Thanks for reporting this. We now handle these cases much more correctly and all of your queries were fixed by #1333 and #1318.

Note that there still might be some inaccuracies wrt to escaping in the various output formats, but the bugs that were responsible for the issues you reported should now all be fixed.