[
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 [email protected].
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 [email protected].
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
