Re: SPARQL Query 1.1 review comments

Andy Seaborne wrote:
> 
>> 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.

This is correct. We don't have a formal resolution here. We did discuss 
it in our November 17 teleconference 
(http://www.w3.org/2009/sparql/meeting/2009-11-17) which showed a clear 
preference (but not unanimity) for requiring aliases.

My suggestion is that this be taken as advice to the editors, rather 
than seeking a formal resolution (unless there are group members who 
request a formal issue be made of it in response to whatever action the 
query editors take).

Lee


> 
> 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 Wednesday, 6 January 2010 09:12:44 UTC