W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > December 2009

Re: Comments on SPARQL 1.1

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 15 Dec 2009 10:15:55 +0000
Message-Id: <92FEA3B0-3EDF-400E-9012-324B09FE34E7@garlik.com>
To: rvesse@dotnetrdf.org
Cc: public-rdf-dawg-comments@w3.org

Thank you for your comments. Responses to your queries are inline below.

 > Hi all
 > Here are my comments/questions on the draft.  Some of this is based  
 > personal opinion and some of this is based on starting to try and  
 > some of this stuff in my SPARQL implementation in my latest  
 > builds of dotNetRDF (early Alpha release .Net RDF library).
 > Aggregates
 > - I definitely support the use of a separate HAVING keyword, I  
agree with
 > Leigh that it makes clear that the type of constraint is different  
and helps
 > SQL programmers make the move to SPARQL by making the syntax familiar

The WG has not yet made a decision on which syntax to use, but the  
editors are currently considering the options.

 > - The proposed grammar has a couple of things which bug me:
 >  1. It allows for a Having clause without a Group By clause which  
 > necessarily make sense depending on the constraint given.  I assume  
that if
 > you have a Having clause without a Group By then it should act as a  
 > on the result set?
 >  The only reason I can see for allowing this is if the having  
clause uses
 > an aggregate then this makes sense in some circumstances e.g.  
seeing whether
 > there are a given number of Triples matching a pattern:
 > SELECT * WHERE {?s a ?type} HAVING (COUNT(?s) > 10)

Currently the proposal is that by default a binding multiset will  
consist of 1 groups containing all solutions. This is compatible with  
the way SQL works. However this design is not final, and may well  
change in the near future.

 >  2. What is the intended meaning of grouping by an aggregate since  
 > grammar permits this?  Should this be permitted at all?

Perhaps not. The grammar does not explicitly rule out all the  
syntactically invalid expressions, some things are left to the  
application, to reduce the complexity of the grammar.

 > - On the subject of which aggregates to include I think the ones  
 > proposed are all useful and I can't think of any obvious missing  
ones.  With
 > regards to how MIN and MAX should operate would it be reasonable to  
 > that since SPARQL defines a partial ordering over values that MIN/ 
MAX should
 > return the minimum/maximum based on that ordering.  This is much  
easier to
 > implement than doing some form of type detection or having some  
 > algorithm for how they operate over mixed datatypes.  While it does  
have the
 > disadvantage or potentially returning different results depending  
on how
 > exactly the SPARQL engine orders values I would be happy with this
 > behaviour.  If people really need type specific minima/maxima then  
they can
 > use appropriate FILTERs in their queries or possibly extra  
aggregates could
 > be introduced eg. NMIN/NMAX (Numeric minimum/maximum)

This is the behavior that the group is proposing to go with.

 > Subqueries
 > - I would appreciate some clearer guidance on variable scoping as I  
 > feel comfortable attempting to implement these until I have a  
better idea of
 > how this should work.

Certainly. The intention is that only variables projected from the  
subquery be in scope in the outer expression.

 > Projection Expressions
 > - I like these very much and have implemented these already.  I  
 > don't like the idea of a LET keyword, it certainly restricts the  
ability of
 > the SPARQL processor to decide in what order it wishes to execute  
the query.
 > Plus to my mind it starts to make SPARQL into the equivalent of  
Transact SQL
 > (and other vendor specific SQL stored procedure languages) which  
feels wrong
 > to me.

The ordering concern is not necessarily a problem, depending on how  
LET would be defined.

Your concern in the second point is noted.

The group has previously decided not to to address LET like structures  
in this version of the recommendation, as yet that decision has not  
been revisited.

Steve Harris,
on behalf of the SPARQL working group.
Received on Tuesday, 15 December 2009 11:16:42 UTC

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