lalewis1
commented
3 months ago More Info.
This works as expected because the internal service query is valid sparql on its own.
...
service <my-service> {
select ?s ?p ?o
where {
?s ?p ?o
}
}
...This results in a POST request because the internal service query is not valid on its own
...
service <my-service> {
?s ?p ?o
}
...However, the above is still valid sparql, and is how Federated queries are documented by the W3C
Suggested Solution Only bind required prefixes to the query if necessary.
Hi All,
Looks like the logic in the way that the _buildQueryStringForServiceCall function gets called is flawed. code here: https://github.com/RDFLib/rdflib/blob/500ec25396730fa1849172b8052d19e9ed574cd4/rdflib/plugins/sparql/evaluate.py#L404
The function only gets passed the inner text from the SERVICE query and then the sparql parser tries to parse it which fails. This then results in a bunch of prefixes being added to the query. making the query always longer than 600 characters.
In turn this then means that a POST request is always used, due to the logic here:
https://github.com/RDFLib/rdflib/blob/500ec25396730fa1849172b8052d19e9ed574cd4/rdflib/plugins/sparql/evaluate.py#L363