Gravsearch AND expression failing

[SepidehAlassi]

Example:
In query below FILTER(?text = "Bonjour" && lang(?text) = "fr") is failing

"""
|PREFIX knora-api: http://api.knora.org/ontology/knora-api/simple/v2#
|PREFIX anything: http://0.0.0.0:3333/ontology/0001/anything/simple/v2#
|
|CONSTRUCT {
| ?thing knora-api:isMainResource true .
|
| ?thing a anything:Thing .
|
| ?thing anything:hasText ?text .
|} WHERE {
| ?thing a knora-api:Resource .
|
| ?thing a anything:Thing .
|
| ?thing anything:hasText ?text .
|
| anything:hasText knora-api:objectType xsd:string .
|
| ?text a xsd:string .
|
| FILTER(?text = "Bonjour" && lang(?text) = "fr")
|}
""".

[benjamingeer]

I think we can do it like this:

My understanding is that lang(?text) = "fr" gets replaced by some statements with no FILTER expression; the original expression becomes a placeholder None. So after this is done, we can traverse the expression tree, simplifying subexpressions that contain None as a branch. For example, if we find an AND expression with None as a branch, we replace the whole AND expression with the other branch.

[benjamingeer]

The way the filter statements are generated at the moment for lang, this can't work. Imagine this filter in Gravsearch:

FILTER(lang(?text) = "fr" || lang(?text) = "en")

This will generate additional statements to check for both conditions, and both sides of the expression will be removed. But all those statements must then match to get a search result, so in effect the OR becomes an AND, which is wrong. Similarly imagine this:

FILTER((?text = "maison" && lang(?text) = "fr") || (?text = "house" && lang(?text) = "en"))

This is valid SPARQL, but in Gravsearch it could never return any results.

The solution is not to remove the expression from the FILTER, but instead to replace it with a comparison that checks the value of a variable, which is set by an additional statement.

In short: if you remove an expression from a FILTER, it has to be the top-level expression, and then you have to remove the whole FILTER, otherwise the logic will be invalid.

[tobiasschweizer]

In short: if you remove an expression from a FILTER, it has to be the top-level expression, and then you have to remove the whole FILTER, otherwise the logic will be invalid.

Ok, I understand! But how would that work for fulltext search? We allow users to use the match function, but internally we are creating a statement using the Lucene index.

[benjamingeer]

I'll add a check to make sure that match is at the top level of the FILTER, and throw an exception if it isn't.

[benjamingeer]

By the way, thank you for refactoring transformFilterPattern, it's so much easier to work on this way! :)

[tobiasschweizer]

I'll add a check to make sure that match is at the top level of the FILTER, and throw an exception if it isn't.

Great!

By the way, thank you for refactoring transformFilterPattern, it's so much easier to work on this way! :)

Also great! I think your idea with the design doc for gravsearch is good, we should try to describe what is implemented in a more formalized way. And I think we will find a lot of inconsistencies.