Re: SPARQL Query 1.1 review comments

On 05/01/2010 2:33 PM, Souripriya Das wrote:
> Andy and Steve,
>
> Thanks for looking at the comments on such a short notice.
>
> You can ignore my comment about 8.1 (Negation Syntax). It was more of a
> minor pretty-printing nit-picking. But, now I see that it is consistent
> with the way the grammar is specified. (Regarding WS, I am assuming that
> whitespaces are allowed between the (NOT) EXISTS and the GroupGraphPattern.)

Yes.  white space (or none) is allowed in the draft grammar.

> Regarding my comments about "value of expression in presence of operands
> of incorrect data types" ("semantics unclear" in Sec 2.5, Sec 13.1.2,
> and Sec 9): The idea of skipping the binding (effectively binding=null?)
> sounds good.
>
> For the query example in Sec 9, I still think it will nicely show the
> grouping aspect if we extend the SELECT list slightly to SELECT ?org
> (SUM(?lprice) AS ?totalPrice).

[Steve]


> One more question: Are we always requiring an alias for an expression?
> That is, would SELECT SUM(?lprice) ... (i.e., without the alias
> ?totalPrice) be allowed?

Not formally decided (I couldn't find a resolution anyway) but there is 
a body of support for requiring the alias name.  If sent over HTP with 
the results format, a name is required.  Just for query, a processor can 
easily generate one at parse time so there is no requirement for it.

Your opinion?

Personally, I think the work to generate a safe one (it's similar to 
calculating SELECT *) is negligible and so a design to the benefit of 
the user is to be preferred.

 Andy

>
> Thanks,
>
> - Souri.
>
>
> ----- Original Message -----
> From: andy.seaborne@talis.com
> To: SOURIPRIYA.DAS@oracle.com
> Cc: public-rdf-dawg@w3.org
> Sent: Tuesday, January 5, 2010 8:40:38 AM GMT -05:00 US/Canada Eastern
> Subject: 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
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Received on Tuesday, 5 January 2010 16:54:16 UTC