During the entry it's shown as a valid SPARQL, but when it's executed it gives an error and an indication where the failure is located, which is in the middle of the postcode-literal. In this error-message the double quotes around the literal are removed.
Similar removals of characters seem to appear on semicolons and pipesymbols.
I have two versions of LDT tested. In version 1.19.1 (which is used in the BAG too) this removal does happen. In version 1.18.1 this removal of characters does not happen.
Side-effect of these removals is that federated queries using the BAG SPARQL-endpoint containing string-literals seem not possible anymore (never give results).
Correct. This was introduced in version 1.19.1 to deal with some security issues. But a bit to strict... This is solved in the latest release of the LDT
When starting the SPARQL-endpoint of LDT it does not accept all characters which are normally valid in a SPARQL-query.
An example using the SPARQL-endpoint of the BAG: https://bag.basisregistraties.overheid.nl/sparql
Enter the following query:
During the entry it's shown as a valid SPARQL, but when it's executed it gives an error and an indication where the failure is located, which is in the middle of the postcode-literal. In this error-message the double quotes around the literal are removed.
Similar removals of characters seem to appear on semicolons and pipesymbols.
I have two versions of LDT tested. In version 1.19.1 (which is used in the BAG too) this removal does happen. In version 1.18.1 this removal of characters does not happen.
Side-effect of these removals is that federated queries using the BAG SPARQL-endpoint containing string-literals seem not possible anymore (never give results).