incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject JENA-195 : a small point of project policy on other-system specific code.
Date Thu, 19 Jan 2012 17:37:40 GMT
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.

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 


-------- 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 <>

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?

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/
--- src/main/java/com/hp/hpl/jena/sparql/engine/http/ 
+++ src/main/java/com/hp/hpl/jena/sparql/engine/http/ 
(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 
("+serviceURL+")") ;
+            serviceParams = true ;

          this.serviceURL = serviceURL ;
@@ -178,7 +179,7 @@
              if ( count() == 0 )
                  target = new URL(serviceURL) ;
-                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

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.



View raw message