RE: ACTION-101 completed: Review of SPARQL 1.1

CVS to revision 119

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Axel Polleres
> Sent: 04 October 2009 23:15
> To: Birte Glimm
> Cc: SPARQL Working Group
> Subject: 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."
> 

We are removing the abstract as the intro has the important material.

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

Done

> 
> 3)
> Example in Section 2, last line in data:
> 
> :book3 :price 7 .
> 
> - should be? ->
> 
> :book4 :price 7 .

Done

> 
> 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 , μ)

The grammar has been updated from the combined grammar.

> 
> 5)
> key/Partition/Aggregation should have consistently lower or upper case
> (already
> mentioned by Birte), suggest
> 
> key(varlist, μ) -> Key(VarList, μ)
> 

Yes


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

There was a transcription error.


> 
> 
> I don't see yet, where the HavingExpression would go in, probably
> 
>   Partition(varlist, Ω)
> 
> here needs to be extended to Partition(varlist, Ω, Constraint)

It's a straight filter over the outcome of aggregation and does not need to be handled in the aggregation step.  When the AST to algebra is done, this will be clear.

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

Ideally, yes but unlikely in the time available.

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

We will need "toMultiSet".

Alternatively, we could work in term of a "table" and not need "toList" and "toMultiSet" but need to note hwne it is or is not ordered.

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

Revised, especially the ORDER BY being lost during evaluation.

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

Things, in a group are combined by join. E.g. { { pattern 1 } { pattern2 } }

> * Section 4:
> 
> 10)
> "in FILTERs"
> 
> -> "in FILTER expressions"
> 

Done

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

Prefer not.  The downside is that if we do one, we ought to do it through out all the documents.

 Andy

Received on Monday, 5 October 2009 17:25:57 UTC