ACTION-101 completed: Review of SPARQL 1.1

My comments on SPARQL/Query 1.1 below. Summarizing, my impression is  
that we should point to issues
probably more concretely in some places, it seems that one or the  
other issue mentioned on the
resp. design page have not yet been propagated to the draft yet, right?

Apart from that, it should be feasible to get this document in shape  
to publish as FPWD
in the planned schedule, IMO.

Axel
=============================================================

1) Suggested rewording for the abstract
(alternatively/additionally, just put an Editor's note that this  
abstract will
need rewording depending on the final features the WG decides.):

"SPARQL contains capabilities for querying required and optional graph
patterns along with their conjunctions and disjunctions. SPARQL also
supports extensible value testing and constraining queries by source
RDF graph. The results of SPARQL queries can be results sets or RDF  
graphs."


->

"SPARQL contains capabilities for querying required and optional graph
patterns along with their conjunctions, disjunctions, and negation.
SPARQL also supports extensible value testing and constraining
queries by source RDF graph. The results of SPARQL queries can be
results sets or RDF graphs. Values in query results can be aggregated
and queries may be nested."




2)
You may want to clarify the status sentence:

"The draft describes the differences between SPARQL/Query 1.0 and the
proposed SPARQL/Query 1.1, rather than being a standalone draft
recommendation."

- change to something like this ->

"This draft describes the differences between SPARQL/Query 1.0 and the
proposed SPARQL/Query 1.1, rather than being a standalone draft
recommendation yet. The final version of this draft shall be
integrated with and replace the original SPARQL/Query 1.0 document."

* Section 2:

3)
Example in Section 2, last line in data:

:book3 :price 7 .

- should be? ->

:book4 :price 7 .

4)
Grammar in Section 2

Having -> HavingExpression

ProjectValues ... no production for that as of yet, actually,
http://www.w3.org/2009/sparql/wiki/Design:Aggregate has


AggregateExpression  ::=  'GROUP BY' ?Var+ HavingExpression?

instead of

GroupBy	::=	'GROUP BY' ProjectValues HavingExpression?

What on top of VariableLists have you thought of here?
Whatever generalisation would go there, would likely also need to  
generalize

key(v, μ)

  to

key(projectvalues , μ)

5)
key/Partition/Aggregation should have consistently lower or upper case  
(already
mentioned by Birte), suggest

key(varlist, μ) -> Key(VarList, μ)


6) The definition of	Partition seems to have a problem, I understand  
that partition is a
set of pairs (k, Omega_k) where Omega_k is the subset of Omega such
that key(key(varlist,mu) = k, i.e.


  Partition(varlist, Ω) = { (k,Ω) | Ω in Ω,  
k=key(varlist, Ω) }

  -->

  Partition(varlist, Ω) = { (k,Partition(varlist, k, &Omega)) |  
k in key(varlist, &Omega)}

  where

  Partition(varlist, k, Ω) = { μ | μ in &Omega such that  
key(varlist, μ) = k }


I don't see yet, where the HavingExpression would go in, probably

  Partition(varlist, Ω)

here needs to be extended to Partition(varlist, Ω, Constraint)

At least a sentence mentioning that this is to be done, should go there.

7)  would suggest to add Example-to-algebra translation analogous to
     the examples in "12.2.2 Examples of Mapped Graph Patterns" of  
current spec  as TODO
    (that probably applies to all features)


* Section 3:

8) You write:

"As it stands Subqueries require no new algebra operators."

Following the current evaluation (with solution modifiers) results  
would need to be
converted from multisets to sequences, so (as mentioned on the design  
page
http://www.w3.org/2009/sparql/wiki/Design:SubSelect) subqueries would  
need a conversion
ToMultiset back from Sequence to MultiSet.


Do I understand correctly, that some content from the design page are  
still to be
propagateed to the draft?

9)


"In general, GroupGraphPatternSub is evaluated as per SPARQL 1.0, and  
the resulting multiset is projected with respect to Project, as Project 
(GroupGraphPatternSub, Project). This is then Joined with the  
enclosing expression.

The ordering from any ORDER BY expressions is not propagated outside  
the Project expression."

Sounds a bit confusing to me, is what you want to point here at the  
issue on
scoping/how the bindings from the outer query are "propagated" inside  
the inner query if there
are solution modifiers, which is necessary e.g.
to get the intended behavior of the example query? ... since if this  
was meant to
be modular, then I don't see the example to work, as

    SELECT ?y ?name WHERE {
       ?y :name ?name
     }
     ORDER BY ?name
     LIMIT 1

evaluated alone would always return,

  ?y :alice  ?name "A. Foo"

as the single answer which wouldn't join with any of the ?y bindings  
of the outer query.
Not sure what would be a good wording, but let me try...


"In general, GroupGraphPatternSub is evaluated as per SPARQL 1.0, and  
the resulting multiset
is projected with respect to Project, as Project(GroupGraphPatternSub,  
Project). This is then
Joined with the enclosing expression where solution modifiers are  
meant to be evaluated after this join.

The solution modifiers are not propagated outside the Project  
expression."

Admitted, not very nice/clear... but what was there before, doesn't  
really sound clear either.
Maybe easiest to just point at the related issue on scoping.
To get the intended behavior, it looks like we'd need to also make  
subselects order dependent and use the

   substitute(pattern, μ)

function used in Section 4?


* Section 4:

10)
"in FILTERs"

-> "in FILTER expressions"


* Seciton 5:

11)

"@@Scoping of variables - does "AS ?v" allow ?v to be used in another  
expression?   No reason why not if careful about solution extension  
ordering."

Should we refer here to concrete issues from the draft? (ISSUE-36 in  
this case)

Received on Sunday, 4 October 2009 22:15:55 UTC