Re: Comments list comments

On Tue, Mar 22, 2005 at 10:14:19AM +0000, Steve Harris wrote:
> 
> 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

+1

I'd like the change the question  from "are people going to complain if
we don't have this feature?" to "is SPARQL useful to many folks without
this  feature?". I  think the  80/20  rule and  "it's version  1" is  a
perfectly valid response to last call requests for features.

> 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
> > 

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.