W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > April 2005

More on WITH and FROM clauses

From: Graham Klyne <gk@ninebynine.org>
Date: Fri, 08 Apr 2005 17:12:48 +0100
Message-Id: <>
To: public-rdf-dawg-comments@w3.org

I've argued elsewhere [1] that I don't think SPARQL should mandate support 
for multiple-graph queries.  I'm having a further difficulty with the WITH 
and FROM clauses that are independent of the un-needed complexity argument 
I make there.

I find that having the WITH and FROM clauses as part of the query language 
radically and unnecessarily curtails my implementation design choices, 
which seems to me like an undesirable property for a 
standard.  Specifically, they bind the query handling logic to the I/O or 
other logic that fetches the graph(s) to be queried -- I think these 
functions should be kept separate so that I can apply the same query to 
different datasets.

My desired implementation has an entry point with a type signature like this:

   parse :: String -> Either String (RDFGraph -> SparqlResult)

This function accepts a string containing a SPARQL query and returns either 
an error or a function that accepts an RDF graph and returns a sparql 
result value.  This allows me to neatly separate execution the query 
language processing from accessing the graphs to be queried and execution 
of the query against that graph.  In particular, the parsing and query 
execution can be pure functions, which generally makes life easier for me.

If I have to access graphs based on URIs embedded in the query, it is no 
longer possible to process a query without (possibly) being required to 
perform I/O, losing some of the simplicity of my preferred solution.

I propose that, even if multiple-graph querying is retained, the WITH and 
FROM elements are made part of the query protocol rather than the query 
language, thereby maintaining a logical separation between the I/O and the 
graph processing elements of query.



Graham Klyne
For email:
Received on Friday, 8 April 2005 16:11:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC