You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2012/01/19 18:37:40 UTC
JENA-195 : a small point of project policy on other-system specific
code.
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
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 <ca...@googlemail.com>
Reply-To: jena-users@incubator.apache.org
To: jena-users@incubator.apache.org
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
Re: JENA-195 : a small point of project policy on other-system specific
code.
Posted by Andy Seaborne <an...@apache.org>.
On 19/01/12 21:26, Paolo Castagna wrote:
> Andy Seaborne wrote:
>> 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.
>
> Not very useful, but it shows users that you can specify query parameters
> in the SERVICE<IRI>:
>
> String queryString =
> "SELECT * WHERE { " +
> " SERVICE<http://dbpedia-live.openlinksw.com/sparql?timeout=10000> { " +
> " SELECT DISTINCT ?company where {?company a<http://dbpedia.org/ontology/Company>} LIMIT 20" +
> " }" +
> "}" ;
> Query query = QueryFactory.create(queryString) ;
> QueryExecution qexec = QueryExecutionFactory.create(query, ModelFactory.createDefaultModel()) ;
> try {
> ResultSet rs = qexec.execSelect() ;
> ResultSetFormatter.out(System.out, rs, query) ;
> } finally {
> qexec.close() ;
> }
>
> Maybe something like this is better (and it should not increase the number
> of questions.
>
> I do not know if the DBPedia service supports other query parameters that
> could make the example more useful/interesting.
>
> Paolo
Good use of DBpedia.
I think it's good to illustrate this with a use of setting the param via
the context (so the timeout is not in the query itself and can be
adjusted more easily). We can use such example code to test the
proposed patch.
Andy
Re: JENA-195 : a small point of project policy on other-system specific
code.
Posted by Paolo Castagna <ca...@googlemail.com>.
Andy Seaborne wrote:
> 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.
Not very useful, but it shows users that you can specify query parameters
in the SERVICE <IRI>:
String queryString =
"SELECT * WHERE { " +
" SERVICE <http://dbpedia-live.openlinksw.com/sparql?timeout=10000> { " +
" SELECT DISTINCT ?company where {?company a <http://dbpedia.org/ontology/Company>} LIMIT 20" +
" }" +
"}" ;
Query query = QueryFactory.create(queryString) ;
QueryExecution qexec = QueryExecutionFactory.create(query, ModelFactory.createDefaultModel()) ;
try {
ResultSet rs = qexec.execSelect() ;
ResultSetFormatter.out(System.out, rs, query) ;
} finally {
qexec.close() ;
}
Maybe something like this is better (and it should not increase the number
of questions.
I do not know if the DBPedia service supports other query parameters that
could make the example more useful/interesting.
Paolo
Re: JENA-195 : a small point of project policy on other-system specific
code.
Posted by Paolo Castagna <ca...@googlemail.com>.
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 <ca...@googlemail.com>
> Reply-To: jena-users@incubator.apache.org
> To: jena-users@incubator.apache.org
>
> 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