Re: query by reference

Kendall Clark wrote:
> Folks,
> 
> Leigh Dodds raised a couple of good issues against our protocol  
> design, one of which actually convinced me: we lost the ability to do  
> query by reference at some point, and I don't know if that was  
> explicitly desired or not. I'm pretty sure we don't have a WG  
> decision directly on point.
> 
> I'd like to propose adding that back to the protocol design.  
> Basically we're talking about adding another parameter (in HTTP),  
> "query-uri", the value of which would be a URI which, when  
> dereferenced, would return a representation of a SPARQL query  
> resource. That would add a third way to "convey a query" to a SPARQL  
> query service:
> 
> a. POSTing a urlencoded query in the body of an HTTP request
> b. serializing a query in a URI (in the 'query' parameter)
> c. 'pointing' at a query on the Web and asking the service to deref  
> and execute it

Probably OK - as long as it's a third way and not a replacement for POST which 
was mentioned in the past.

There are some issues that arise with this (and incidently, much of this 
applies to graph specification in the protocol and FROM as well).

1/ A query processor may not be able to issue GET requests to pull the query. 
  A common data centre architecture is front-end web servers directing 
requests to backend machines.  The back end machines are firewalled off and 
only talk to the front end processors and other backend systems.  They can't 
reach out to the web (nor be reached which is the real point).

[This (on a smaller same-machine scale) affects Joseki because the query 
engine is common to which route in the request comes.  The dataset is shared 
across connections.]

2/ POST is still needed if the client is inside a firewall, indirection for a 
large query is not always possible.

3/ Presumably, the "query-uri" can be deferenced by any means, including 
naming a query already on the server?  This is mainly a spec language issue. 
This is a useful feature - it's a light-weight form of prepared query.

> 
> I don't believe this opens any additional security or implementation  
> burdens since:
> 
> - we already allow arbitrary URIs to be deref'd to load data
> 

If the request is transmitted over SOAP, isn't it odd that the query engine is 
doing a GET?

> - whatever sanity checks one would implement (or specify) re:  
> executing an arbitrary SPARQL query conveyed via (a) or (b) also  
> apply to (c), and I don't believe (c) adds any additional constraints  
> or holes (but I'm *not* a security expert)...
> 
> I think I could make a pretty good Use Case argument for this  
> feature, FWIW.
> 
> Leigh's comments and our subsequent conversation:
> 
> http://www.w3.org/mid/4367C67C.6000904@ldodds.com
> 
> (There should probably be some restriction on the presence of query  
> and query-uri parameters, of course. Only one or the other can be  
> present in an In Message, not both.)
> 
> Cheers,
> Kendall

What error conditions will be signalled back to the client on fetch errors?

	Andy

Received on Wednesday, 16 November 2005 13:57:09 UTC