Hi Andy Seaborne wrote: > The patch for JENA-195 from Paolo includes a Kasabi-specific example in > the ARQ examples. The example is both specific to Kasabi and to a > particular Kasabi dataset.
... and it requires an API key (in an environment variable), with hindsight not a good idea. :-) I removed it and posted a new patch without that example. Paolo > > There is already a DBpedia example so we have included a > service-specific examples before. DBpedia is used by students and in > student projects so we do get a stream of questions about using it, > especially as it can be peculiar in its timeout behaviour. > > However, this case is different because Kasabi requires registration to > obtain an API key and the example does not work without such > registration. The key is required to be in environment variable > KASABI_API_KEY, which is the way all Kasabi client APIs deal with the > API key. > > A committer can not test the example unless they register with Kasabi. > This, to me, is the critical difference here. > > Personally, I think such examples should go on the Kasabi site and not > in the jena-arq codebase, and eventually Jena examples area which Ian's > been setting up. > > If the majority feel this is acceptable, then I will not block it being > included. > > Andy > > -------- Original Message -------- > Subject: Re: Using SERVICE with parameters: HttpException: -1 URL > already has a query string > Date: Thu, 19 Jan 2012 08:40:41 +0000 > From: Paolo Castagna <[email protected]> > Reply-To: [email protected] > To: [email protected] > > Andy Seaborne wrote: >>> My colleague was using arq.query command line, so he was trying to >>> specify >>> additional query parameters in his SPARQL queries writing: >>> >>> SELECT ... WHERE { >>> SERVICE<...?name1=value1> { ... } >>> SERVICE<...?name2=value2> { ... } >>> } >>> >>> I don't think this is allowed by the SPARQL grammar. Is it? >> >> Have you tried the online query validator? >> >> http://www.sparql.org/query-validator.html >> > > Hi Andy, > at first, I did not try the validator (I should have). > I looked at the SPARQL grammar [1] instead. > > In particular, the thing I am still not sure is if <http://.../?name=value> > is ok as IRI_REF [2]. > > The on-line validator has no problems with SPARQL queries containing: > SERVICE <http://.../?name=value>. Good. > > ARQ currently throws an exception if someone attempts to use query > parameters in a SERVICE <IRI>. > > We now have a patch [3] which, instead of throwing an exception when '?' > is found in the SERVICE <IRI>, keep the query string parameters and send > them to the remote SPARQL endpoint as is. Here is the relevant bit: > > Index: src/main/java/com/hp/hpl/jena/sparql/engine/http/HttpQuery.java > =================================================================== > --- src/main/java/com/hp/hpl/jena/sparql/engine/http/HttpQuery.java > (revision > 1232106) > +++ src/main/java/com/hp/hpl/jena/sparql/engine/http/HttpQuery.java > (working copy) > @@ -68,6 +68,7 @@ > String responseMessage = null ; > boolean forcePOST = false ; > String queryString = null ; > + boolean serviceParams = false ; > > //static final String ENC_UTF8 = "UTF-8" ; > > @@ -97,7 +98,7 @@ > log.trace("URL: "+serviceURL) ; > > if ( serviceURL.indexOf('?') >= 0 ) > - throw new QueryExceptionHTTP(-1, "URL already has a query > string > ("+serviceURL+")") ; > + serviceParams = true ; > > this.serviceURL = serviceURL ; > } > @@ -178,7 +179,7 @@ > if ( count() == 0 ) > target = new URL(serviceURL) ; > else > - target = new URL(serviceURL+"?"+qs) ; > + target = new URL(serviceURL+(serviceParams ? "&" : > "?")+qs) ; > } > catch (MalformedURLException malEx) > { throw new QueryExceptionHTTP(0, "Malformed URL: "+malEx) ; } > > > This would solve the problems for people wanting to run SPARQL queries > against SPARQL endpoints which support/require additional query parameters. > > The JENA-195 [4] has more details on this and the latest patch attached > has more changes (the change above is just for HttpQuery.java). > > Pending some feedback, I'd like to commit that. I think now it is in a > much better shape (but if there are better ways, I am happy to further > improve it). > > Let me know what you think. > > Thanks, > Paolo > > [1] http://www.w3.org/TR/sparql11-query/#sparqlGrammar > [2] http://www.w3.org/TR/sparql11-query/#rIRI_REF > [3] > https://issues.apache.org/jira/secure/attachment/12510753/JENA-195.patch > [4] https://issues.apache.org/jira/browse/JENA-195
