On 15/01/12 09:42, Paolo Castagna wrote:
Andy Seaborne wrote:
On 13/01/12 17:19, Paolo Castagna wrote:
Paolo Castagna wrote:
Or, the SPARQL specs explicitly forbid that... probably here, isn't it?
http://www.w3.org/TR/sparql11-query/#rIRI_REF
Luckily, QueryEngineHTTP has an addParam(...) method. However, I did
not find
a way do go around this within a SPARQL query using SERVICE.
This isn't as friendly as using SERVICE directly within the SPARQL
queries.
Would it be possible to change Service.java [1] and allow developers
to set
custom/additional query string parameters on a per service URI basis?
Or, alternatively, HTTP request parameters?
Paolo
[1]
http://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/trunk/src/main/java/com/hp/hpl/jena/sparql/engine/http/Service.java
It's a ordering/%-encoding issue. Which version is this? trunk?
Hi Andy,
I think it was the arq.query command from ARQ included in the Fuseki SNAPSHOT.
But, I had a look at the QueryEngineHTTP and QueryHTTP code in ARQ trunk and
the same exception will trigger if someone attempts to use SERVICE and a URI
with some parameters already set (which I think it is forbidden by the spec).
Isn't it?
Paolo
Of the two different solutions in this thread, it seems that either can
work.
1/ Service.java code could look in the Context for additional parameters
- but how might the code know which endpoints need which parameters?
(there may be several SERVICE calls to different places in one query -
don't want APi keys exposed to the wrong places!)
2/ Just not checking for "?" doesn't quite work (need to know there is a
"?" allowed and swap to "&") but API keys probably shouldn't be in
SERVICE URIs. Is there any other query string parameters that might
reasonably and sensibly be in the service URI? If it's just keys, then
(1) looks better. Or both.
What might a general design look like?
IIRC someone was looking to rework HttpQuery and see JENA-56.
Andy
