Re: SPARQL Query 1.1 review comments

Souri- thank you for you comments which are addressed below toegther 
with Steve's earlier mesaage.

On 05/01/2010 5:19 AM, Souripriya Das wrote:
>
> Here are my (slightly rushed :-)) review comments:
>
>     * [Section 2.5: Creating Values with Expressions]
>           o [semantics unclear] If a solution for a query with "SELECT
>             ?x ?y ..." would include bindings ?x="10"^^xsd:integer and
>             ?y="Hello", then what would happen to that solution for
>             "SELECT ?x+?y ..."?
>                 + Would that solution be skipped (i.e., Is there an
>                   implicit directive that a solution is returned only
>                   if all the SELECT-list expressions can be evaluated
>                   without error?)?
>                 + The solution would be returned, but the value of the
>                   expression will show up as error.
>

There are three design possibilities - whole results are an error, skip 
the row or skip just the binding.  Binding an error token is strange 
(typing; and also whether it itself can occur RDF). I think that causing 
everythign to be an error is bad because it does not scale and is at 
odds with the SPARQL design.

The design I have in mind skips just the binding.  The extend operator 
works on one binding, not an entire row.  I have fixed the definition 
(it had an "and" where it needed "or").

     extend(μ, var, expr) = μ if var not in dom(μ) *or* eval(expr) is an 
error

>           o [would like to know] Are we allowing expressions for
>             CONSTRUCT as well?
>

There are no plans for that - it can be done with sub-SELECT.

>     * [Section 3: RDF Term Constraints (Informative)]
>           o [typo] Subsections for Section 3 show only "3.1 Other Term
>             Constraints" in the content, but there are two other
>             subsections: "3.1 Restricting the Value of Strings" and
>             "3.2 Restricting Numeric Values".
>

The XML was malformed for the xmlspec.xsl script.  Fixed.

>     * [Section 13.1.2: "SELECT expressions"]
>           o [typo] change: SELCT => SELECT
>
Done

>           o [semantics unclear] What is the value of an expression if
>             any of the operands of an operator does not have the
>             proper data type? Do we ignore (i.e., not return) the
>             corresponding solution? Or, do we return a
>             pre-designated RDF error term in place of the value of
>             that expression?
>                 + For example, if the RDF data shown is altered to
>                   replace: the triple, :*book1  ns:price  42*, with
>                   *:book1  ns:price  "priceless*", then what will be
>                   the results for the two queries?
>

See sec 2.5. comment above.

>     * [Section 9: Aggregate Functions]
>           o [semantics unclear] Somewhat similar question as in the
>             case of SELECT expressions: How to evaluate an expression,
>             in this case aggregate functions, in presence of values of
>             different types? For example, what would be ?totalPrice if
>             instead of *:book3 :price 7, *we had :*book3 :price
>             "priceless*"?
>           o [enhance the query] In the query example, could we extend
>             the SELECT list from SELECT (SUM(?lprice) AS ?totalPrice)
>             to, say, SELECT ?org (SUM(?lprice) AS ?totalPrice),
>             or further extend to SELECT ?org COUNT(DISTINCT ?author)
>             (SUM(?lprice) AS ?totalPrice)? Just selecting SUM(?lprice)
>             is not very interesting.
>     * [Section 10: Subqueries]
>           o [fix the query] The query does not seem right.
>             Specifically, the outer SELECT list cannot include ?name
>             which is not exposed by (that is, not in the SELECT list
>             of) the subquery. [Also, a minor typo: has an extra '}'.]
>             One possible way to fix it would be:
>
>         PREFIX : <http://people.example/>
>         PREFIX : <http://people.example/>
>         SELECT ?y *?minName*
>         WHERE {
>           :alice :knows ?y .
>           {
>             SELECT ?y (MIN(?name) *AS ?minName*)
>             WHERE {
>               ?y :name ?name .
>             } GROUP BY ?y
>           }
>         }
>
>           o [more details needed] May need more details about the
>             scope of variables mentioned in the subquery.
>     * [Section 8.1: Negation Syntax]
>           o [typo] We need to put a blank space between 'EXISTS' (or
>             'NOT EXISTS') and GroupGraphPattern
>
I don't understand this comment.  Exactly which point in the doc are you 
referring to?

Or do you mean the grammar needs to specify a space is needed between 
EXISTS and GrroupGraphPattern (it's not - covered by the WS rules of the 
grammar).


     Andy