more on FROM's necessity

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

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.

Received on Friday, 1 October 2004 17:43:50 UTC