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 (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/01/19 18:31:40 UTC
[jira] [Issue Comment Edited] (JENA-195) Allow users to specify
query parameters when they use SERVICE <...?name=value> in their SPARQL
queries
[ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189219#comment-13189219 ]
Andy Seaborne edited comment on JENA-195 at 1/19/12 5:30 PM:
-------------------------------------------------------------
Discussion of Kasabi-specific examples taken to jena-dev@i.a.o.
There seem to be two ways to do the same thing - include in the service URI string and in context parameter. Which is best practice? As it stands, there's checking (e..g use of "query" by one rounte and not the other. Is that intentional?
I can actually see use case where specifying default or named graphs actually makes sense. Some systems use them to select the graphs to query over from the set of locally stored graphs. TDB is such a system.
So I'm unclear what the design policy is in this area and think it might get confusing.
was (Author: andy.seaborne):
Discussion of Kasabi-specific examples taken to jena-dev@i.a.o.
There seem to be two ways to do the same thing - include in the service URI string and in context parameter. Which is best practice? As it stands, there's checking (e..g use of "query" by one rounte and not the other. Is that intentional?
I can actually see use case where specifying default or named graphs actually makes sense. Some systems use them to select the graphs to query over from the set of locally stored graphs. TDB is such a system.
So I'm unclear what the design polciy is in this area and think it might get confusing.
> Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries
> ------------------------------------------------------------------------------------------------------
>
> Key: JENA-195
> URL: https://issues.apache.org/jira/browse/JENA-195
> Project: Jena
> Issue Type: Improvement
> Components: ARQ
> Reporter: Paolo Castagna
> Assignee: Paolo Castagna
> Priority: Minor
> Attachments: JENA-195.patch, JENA-195.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> SPARQL endpoints might require or allow additional query parameters, if we want to use those endpoints with SERVICE <...> in SPARQL queries we must support query parameters and allow users to use SERVICE <...?name=value> in their SPARQL queries.
> Service.java can look in the Context for additional parameters.
> Parameters need to be kept separate and grouped on a per SERVICE endpoint basis (in order to avoid exposing parameter values to wrong places).
> A Map<String, Map<String,List<String>>> can be uses to map SERVICE endpoint URLs to parameter-->values.
> OpService.java probably needs to change (to keep the parameters separate from the SERVICE endpoint URL).
> See also this thread on jena-users: http://markmail.org/thread/wc5hvr3b3uzy2mrk
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira