You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Paolo Castagna (Created) (JIRA)" <ji...@apache.org> on 2012/01/16 09:20:38 UTC

[jira] [Created] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

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


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



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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189223#comment-13189223 ] 

Andy Seaborne commented on JENA-195:
------------------------------------

In the example (remote_01 and remote_04) you have to specify the environment variable even if the API key is in the service URI.
                
> 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

        

[jira] [Issue Comment Edited] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Andy Seaborne (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
    [ 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment: JENA-195.patch

Thank you Andy.

This patch improves the javadoc and provides an additional example (i.e. ExampleKasabi.java) which needs a Kasabi API key to be run. Maybe not a good idea to include this as an example, but this is the real use case where this issue come from.
A QueryExecException is thrown if someone overrides a SPARQL protocol query parameter via Context.
I'll further improve the documentation, as the code settles. 

Things I am not sure about are: encoding policy and Explain.explain.

QueryEngineHTTP.addParam doesn't encode values, I followed the same approach for consistency. Is this the right thing to do?
I need to look more at Explain.explain and find out what's the best way to report logging informations.

> Maybe it's time to have a page on the website for all-things-remote, including this feature

If/when a page for all-things-remote is added to the website, I'll add a section there when this issue is closed. I am not sure if I know all of the all-things-remote.
                
> 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment: JENA-195.patch
    
> 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
>
>   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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187005#comment-13187005 ] 

Andy Seaborne commented on JENA-195:
------------------------------------

As it stands, I think it will be tricky for users to know what this feature is and how it works without having to delve into the implementation code.

1/ This needs a bit more in the javadoc to expose it to users.  I don't think javadoc should point to JIRA which points to an email thread, rather the javadoc should contain the documentation for the implemented design without reference elsewhere. e.g. what is the key in the Map?  what's the value?  encoding policy?  Reserved words?

2/ In addition to javadoc and other documentation, how about an example in src-examples? c.f. ExampleDBpedia

3/ Shouldn't this also work with QueryEngineHTTP?  If it's in QueryEngineHTTP then it works for SERVICE and QueryExecutionFactory.sparqlService.

4/ Might this need some Explain.explain?  I'm not sure what the best level is here, whether the post param-building string needs logging (cryptic but complete) or the query (readable but incomplete).

Maybe it's time to have a page on the website for all-things-remote, including this feature.

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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment: JENA-195.patch

A small additional change in HttpQuery so that SERVICE <...?param1=value1&param2=value2> can be used.
                
> 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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189219#comment-13189219 ] 

Andy Seaborne commented on JENA-195:
------------------------------------

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

        

[jira] [Closed] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Closed) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna closed JENA-195.
-------------------------------

    
> 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
>             Fix For: ARQ 2.9.1
>
>         Attachments: JENA-195.patch, 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment: JENA-195.patch

Removed example, not a good idea. :-)
                
> 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, 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment: JENA-195.patch

Two more examples.
                
> 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment:     (was: JENA-195.patch)
    
> 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
>
>   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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Comment: was deleted

(was: Two more examples.)
    
> 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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189380#comment-13189380 ] 

Andy Seaborne commented on JENA-195:
------------------------------------

The context way is essential.  We can not require API keys, or other security-related information, to be in queries.

The combined approach is fine - it's the principles of error checking I'm asking about.


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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197734#comment-13197734 ] 

Andy Seaborne commented on JENA-195:
------------------------------------

Please ensure there are no warnings in the codebase - the javadoc change introduced one.

(If this is completed, could you close it please? Or what is needed to close it?)

                
> 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
>             Fix For: ARQ 2.9.1
>
>         Attachments: JENA-195.patch, 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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196201#comment-13196201 ] 

Hudson commented on JENA-195:
-----------------------------

Integrated in Jena_ARQ #430 (See [https://builds.apache.org/job/Jena_ARQ/430/])
    JENA-195

HttpQuery and QueryEngineHTTP consistently throw a QueryExecException exception if a 'query' parameter is specified with SERVICE.
Added a couple of examples (i.e. ExampleDBPedia2|3) to show the two ways to specify a query parameter with SERVICE.

I hope everything is fine now. If not, let me know and I'll fix it directly in trunk.

castagna : 
Files : 
* /incubator/jena/Jena2/ARQ/trunk/ChangeLog.txt
* /incubator/jena/Jena2/ARQ/trunk/src-examples/arq/examples/ExampleDBpedia2.java
* /incubator/jena/Jena2/ARQ/trunk/src-examples/arq/examples/ExampleDBpedia3.java
* /incubator/jena/Jena2/ARQ/trunk/src/main/java/com/hp/hpl/jena/query/ARQ.java
* /incubator/jena/Jena2/ARQ/trunk/src/main/java/com/hp/hpl/jena/sparql/engine/http/HttpQuery.java
* /incubator/jena/Jena2/ARQ/trunk/src/main/java/com/hp/hpl/jena/sparql/engine/http/QueryEngineHTTP.java
* /incubator/jena/Jena2/ARQ/trunk/src/main/java/com/hp/hpl/jena/sparql/engine/http/Service.java

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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Comment: was deleted

(was: See also: http://markmail.org/thread/wc5hvr3b3uzy2mrk)
    
> 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
>   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).

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

        

[jira] [Resolved] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna resolved JENA-195.
---------------------------------

       Resolution: Fixed
    Fix Version/s: ARQ 2.9.1
    
> 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
>             Fix For: ARQ 2.9.1
>
>         Attachments: JENA-195.patch, 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment: JENA-195.patch

Two more examples.
                
> 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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186767#comment-13186767 ] 

Paolo Castagna commented on JENA-195:
-------------------------------------

See also: http://markmail.org/thread/wc5hvr3b3uzy2mrk
                
> 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
>   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).

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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

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


  was:
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).



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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198040#comment-13198040 ] 

Paolo Castagna commented on JENA-195:
-------------------------------------

> Please ensure there are no warnings in the codebase - the javadoc change introduced one. 

Missed that, apologies. 
Thanks for fixing it.
                
> 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
>             Fix For: ARQ 2.9.1
>
>         Attachments: JENA-195.patch, 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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189383#comment-13189383 ] 

Paolo Castagna commented on JENA-195:
-------------------------------------

> The context way is essential. We can not require API keys, or other security-related information, to be in queries. 

Ack.

> The combined approach is fine - it's the principles of error checking I'm asking about. 

Do you see any problem if I implement 2/ (consistently for the two ways)?
That seems to be a reasonable choice, given that you see a "use case where specifying default or named graphs actually makes sense".


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

        

[jira] [Commented] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189368#comment-13189368 ] 

Paolo Castagna commented on JENA-195:
-------------------------------------

> So I'm unclear what the design policy is in this area and think it might get confusing. 

Ack.

I see three options:
1/ no checks
2/ we check and throws an exception if the "query" parameter is present
3/ we check and throws an exception if any of the parameters used by the SPARQL protocol is present

Probably, 2/ is the best thing to do. 

If that seems reasonable, I'll do that and make sure the two ways behave the same.
Indeed, now that I tried both ways, perhaps the solution via context is not as easy to use and it should be removed.
                
> 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, 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment:     (was: JENA-195.patch)
    
> 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

        

[jira] [Updated] (JENA-195) Allow users to specify query parameters when they use SERVICE <...?name=value> in their SPARQL queries

Posted by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-195:
--------------------------------

    Attachment:     (was: JENA-195.patch)
    
> 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
>
>   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