- From: Souri Das <Souripriya.Das@oracle.com>
- Date: Tue, 05 Jan 2010 12:58:28 -0500
- To: Andy Seaborne <andy.seaborne@talis.com>
- CC: public-rdf-dawg@w3.org
- Message-ID: <4B437DC4.30107@Oracle.com>
Andy,
> 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
/
My opinion would be to require an alias name, mainly because of the
following:
* Specifying a binding for an alias variable works uniformly for
everything: 1) in Results XML format 2) as an "output" variable of
a subquery that can be referenced in outer query, and 3) in a
top-level query.
* Although it does put a burden on the user to come up with the name
of a variable that is not potentially bound, it makes the query
appear much clearer.
Thanks,
- Souri.
Andy Seaborne wrote:
>
>
> 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 18:00:28 UTC