Re: Comments list comments

This is a general comment on feature creep.

While these are useful features, they are complicated to test, time
consuming to implement, and I dont really want a precident for us adding
every feature that someone requests on the comments list.

If we carry on at this rate will will end up with something (eventually)
that is essentially SQL for triples, but woefully underspecified. The SQL
'92 spec is large, and still not extensive enough to give real
interoperability between SQL systems. I dont want SPARQL to fall into the
same trap when we have a chance to make a clean start with real
interoperablity. Every complicated feature that gets added coumpunds the
risk that a significant proportion of developers will not support some
part of the specification, preventing interop.

- Steve

On Mon, Mar 21, 2005 at 04:04:29 +0000, Andy Seaborne wrote:
> 
> Matters arising from the comments list:
> 
> 
> 1/ SELECT to involve expressions
> 
> SQL allows constants and expressions in explicit projections (SQL SELECT in 
> other words)
> 
>   SELECT ?x "constant" ...
>   SELECT ?x (?x+?y) ...
> 
> Combined with nested SELECTs and UNIONs, we would have a way to tag which 
> branch of a union a solution came from.  This can already be done using 
> different variables in each branch.
> 
> This would require access to results by column number (or aliases which are 
> not required by SQL) and so have impact on the results format.
> 
> At the moment, SPARQL UNION is defined without the explicit SELECT 
> projection and is a graph pattern operator.  There is no no assignment of 
> values - it's not possible to return RDF terms that are not in the graph or 
> a dataset label.
> 
> 
> 2/ GROUP BY
> 
> Request for SQL-like GROUP BY in addition to ORDER BY.  GROUP BY allows the 
> application of aggrgeate functions which is more problematic than ORDER BY 
> (that only chnages the order of solutions, it does not remove, add or 
> change solutions).  It's use with aggregation functions like sum(), count() 
> that is tricky because of defining what is being counted (names or 
> individuals).
> 
> COUNT() can lead to a significant decrease in network bandwidth but I have 
> not seen a proposal as to what it means for RDF query that explciitly 
> addresses the closed world assumptions.
> 
> 
> 	Andy
>

Received on Tuesday, 22 March 2005 10:14:22 UTC