Re: more on FROM's necessity

On Fri, Oct 01, 2004 at 07:54:48PM +0100, Seaborne, Andy wrote:
> >[k@rosa dawg]$ sparql --query=./q.spql --target=/var/data/foaf.rdf
> 
> By placing it on the command line, or in a script, there are two places 
> that need to be coordinated.  Managing more than a few such pairs leads to 
> mistakes in deployment.  

Sorry, I guess I wasn't clear. I was suggesting that it could be
removed even in the 'queries in scripts' scenario because, in that
case, you'd just do target graph selection on, say, the command line,
as above. That's one place, not two. :>

> It's a consequence of your "semantic 
> completeness" in a practical setting.  I don't think we need FROM - but I 
> can see usages where its convenient.

Yes, I don't argue that it isn't convenient. I think I'm settling in
on the idea that FROM should always be optional and that target graph
selection in the protocol trumps target graph selection in the query
(i.e., the FROM) if they disagree.

This supports all the cases we care about and have identified:

1. Queries in "scripts" -- user can use FROM or some environment
   mechanism which is tool-specific.

2. Queries in public URIs w/out any FROM clause, so that queries can
   be applied to arbitrary graphs w/out any change.

3. Smart clients can sniff queries and feed the protocol layer with
   target graph selections based on FROM -- which the query processor
   is free to ignore because target graph selection in the protocol is
   what counts.

   (One of my protocol design goals is that protocol may convey *any*
   RDF query language, not just Sparql. Which means no query language
   dependencies in the protocol layer. This will require
   multi-language smart clients to be able to sniff any RDF query
   language they transport, but: (1) writing a smart client is hard,
   (2),  and this isn't a protocol dependency.)

4. Dumb clients can avoid having to sniff queries, offering some API
   for doing target graph selection, which is conveyed to the server
   via the protocol.

5. In pathological cases where there is a mismatch between the target
   graphs selected by protocol and in FROM, *protocol* wins (though we
   may want to allow query processor to warn user, raise a fault,
   refus to run query, etc.)

The open question remains what a query processor is required to do, if
anything, and what it is allowed to do when there is mismatch between
the set of target graphs identified by the protocol and the set
identified by FROM. My initial thought is that query processors are
free to execute the query with the target graphs selected by the
protocol, no matter what FROM says. But they should be allowed to
refuse to execute the query and to return some kind of 'malformed
request' response similar to HTTP 400.

I'm going to go forward with the protocol draft under these
assumptions. :>

Kendall

Received on Friday, 1 October 2004 19:46:24 UTC