Some comments on F&R

IRC @10:56 GMT+1:
------
<kjetil> folks, please have a glance at the F&R now: http://www.w3.org/2009/sparql/docs/features/

<kjetil> it is pretty complete with what we have now
<kjetil> a few issues, and I haven't written a lot about HTTP Updates yet
<kjetil> I'm running off to lunch now, will continue working on it after lunch
------

Initial comments based on a single, hurried pass over the working draft:

 Andy


Could we manage the text for the doc on the wiki?

Need a summary/overview with the list of features.  This is probably more important than the details.


2.1 : Using AVG as the example is trouble - might imply casting for example.

(Personally, I don't like examples that don't parse - I prefer it that the PREFIXes are included).

2.2.2 but generally comment:

"""
That feature could be used, for instance, in the following use cases:
"""
Not sure "could be used" is helpful without spelling out how it would be done, but that gets into far too much detail. Maybe just stick to the basic point.  


2.2.3: ARQ syntax is wrong.
It's {} not ()


General comment:
There are links to the issues.  This seems strange for a doc that is published.  
Maybe maintain the feature->issue mapping on the wiki and mention once at start of doc.

2.3: Negation.

"Hence, a new syntax is desired."

The discussions so far have not been able just syntax.  The text implies to me that it is just syntax for writing OPTION/!BOUND.

The example of MINUS might be taken to imply that is the likely direction of the WG because it's the only example.

Mention EXISTS and NOT EXISTS in SQL.

2.4: Project expressions

"Being able to project expressions from result bindings, rather than literal values in the store."
==>
"Being able to return the values of expressions over result bindings, rather than just RDF terms in the store."


This is not true (it may be likely to be the outcome but it isn't true on it's own at the moment):
"This feature is necessary for projecting the results of aggregate functions."


2.4.3:

"though that might be unparseable or something along the lines of"
Drifting into discussion?


2.5: Service description
"""
@@ Shoud it go in SPARQL/Query or in another dedicated sub-part of SPARQL, e.g. SPARQL/Protocol ?
"""

Own section - "Service Description".  It isn't query or protocol.

3 SPARQL/Update 1.0

Motivation needs to talk about collections of (named?) graphs.

--------------------------------------------
  Hewlett-Packard Limited
  Registered Office: Cain Road, Bracknell, Berks RG12 1HN
  Registered No: 690597 England

Received on Tuesday, 9 June 2009 12:07:20 UTC