I'm using TopBraid Composer Free Edition (TBC FE) Version 5.1.3. I'm building SPIN rules / CONSTRUCT queries. Part of my query has a FILTER statement with multiple OR'd conditions. I enter it into TBC FE as follows:
FILTER (
(?orgString = SUBSTR("AF X"^^xsd:string, 1, 4)) ||
(?orgString = SUBSTR("J X"^^xsd:string, 1, 4)) ||
(?orgString = SUBSTR("AR X"^^xsd:string, 1, 4)) ||
(?orgString = SUBSTR("N X"^^xsd:string, 1, 4)) ||
(?orgString = SUBSTR("NS X"^^xsd:string, 1, 4)) ||
(?orgString = SUBSTR("MC X"^^xsd:string, 1, 4))
) .
But, when I save the SPIN rule in TBC FE, it regroups the OR'd conditions to be a set of binary OR's:
FILTER (
(((((?orgString = SUBSTR("AF X"^^xsd:string, 1, 4)) ||
(?orgString = SUBSTR("J X"^^xsd:string, 1, 4))) ||
(?orgString = SUBSTR("AR X"^^xsd:string, 1, 4))) ||
(?orgString = SUBSTR("N X"^^xsd:string, 1, 4))) ||
(?orgString = SUBSTR("NS X"^^xsd:string, 1, 4))) ||
(?orgString = SUBSTR("MC X"^^xsd:string, 1, 4))
) .
My question is: why the regrouping? I've used other SPARQL editors and end points that did not do this regrouping. I contend that this makes my code much harder to read (cost), so I'm wondering what the benefit is?
Also, if this is regrouping is not necessary, is there a way to turn it off in TBC FE?
Thanks.
PS: Yes, I know that taking a substring of a literal string seems stupid. I'm doing it to avoid a bug in Sesame that trims my literal strings when I load my RDF file I save from TBD FE into Sesame. The bug has been reported and is being addressed. When it's fixed, I'll upgrade my Sesame version and remove these ugly substrings.
It's the way Jena print queries, not an aspect of TBC FE. For an binary operator that is left associative the parser creates the expression tree (( E1 op E2 ) op E3 ) and it is printed like that. It is simple and safe; printing expressions does not take precedence into account.
An alternative way to write your
FILTER
isin case that is any help.