Re: more on FROM's necessity

Kendall Clark wrote:
> If I understand Andy correctly, he says that we may still need FROM in
> Sparql for cases where Sparql queries live in files -- in the absense
> of a protocol or network, presumably -- and the user merely wants to
> feed these to a query processor and get back results.
> 
> That's an interesting use case, though not one I've thought much
> about. But it doesn't *require* FROM. One could easily do target graph
> selection in, say, command line args:
> 
> [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.  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.

> 
> Works for me.
> 
> I said earlier that one of the costs of removing FROM is a lack of
> semantic completeness; and, I suppose, it tends to make queries less
> declarative, though I wonder about that.
> 
> But there's also a general benefit, namely, it means that queries
> aren't graph-specific, so I store a canonical query at a URI and then
> "compose" them with graphs stored at other URIs, and I don't have to
> change the query when going from graph to graph. That's pretty
> powerful, IMO, and is reminiscent of DanC's demonstration of one of
> the goodnesses of cwm's log:semantics. Queries are, IMO, first class
> terms in this domain, which suggests they should have URIs in some
> cases. If they also don't have FROM clauses explicitly, that makes
> them more generally useful.
> 
> At the very least, then, we should make FROM totally optional, if not
> remove it altogether.
> 
> Kendall Clark
> 
> PS--If removing it makes folks very nervous, we could always treat it
> as a cue to the client, which is conveying the query to a query
> processor, whether locally or via a network. 
> 
> In that case, a particularly smart client will sniff the query, parse
> the FROM clause and indicate in some protocol-specific way the target
> graphs for the query, and then the query processor can effectively
> ignore FROM, either at parse time or in its AST or whenever. In this
> case, target graph selection is effectively done purely in the
> protocol layer, even if the protocol layer is fed from the query.
> 
That's a nice characterisation - "protocol layer is fed from the query".

	Andy

Received on Friday, 1 October 2004 18:55:12 UTC