ql:contains-word rejects string literals with explicit xsd:string datatype

[ddeboer]

Description

The ql:contains-word function rejects string literals that have an explicit ^^xsd:string datatype suffix, even though "text" and "text"^^xsd:string are semantically equivalent in SPARQL.

Query that fails

PREFIX ql: <http://qlever.cs.uni-freiburg.de/builtin-functions/>

SELECT * WHERE {
  ?text ql:contains-word "amsterdam"^^<http://www.w3.org/2001/XMLSchema#string> .
}

Expected behaviour

The query should work, treating "amsterdam"^^xsd:string the same as "amsterdam".

Context

This issue arises when using Comunica with initialBindings. Comunica's Traqula serializer adds explicit ^^xsd:string datatypes to bound string literals when re-serializing queries, which causes QLever to reject them.

Workaround

We're currently stripping the explicit datatype in our client before sending queries to QLever.

[hannahbast]

@ddeboer The ql:contains-word and ql:contains-entity predicates are deprecated, you should use materialized views together with ql:has-word from #2579 . It is not merged yet, but will be in the next days. It is at least as efficient, much more flexible, and easier to use.

Can you describe your use case a little bit more? Then I can give you instructions on what to do for that case. In particular: Is your use case keyword search in literals? Or do you really want to do keyword search in text associated with certain IRIs? The latter is what folks usually want (search for IRIs, not search for literals)

[ddeboer]

@hannahbast Yep, we’re searching for IRIs.