Comments list comments

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 Monday, 21 March 2005 16:22:59 UTC