Re: SPARQL Query 1.1 review comments

FWIW, I agree with Souri. If the system comes up with a unique alias
name, it may make the results confusing...

Ivan

On 2010-1-5 18:58 , Souri Das wrote:
> 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
>>> ______________________________________________________________________
> 
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf