- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 01 Oct 2004 19:54:48 +0100
- To: kendall@monkeyfist.com
- Cc: public-rdf-dawg@w3.org
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