- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 6 Jan 2010 06:07:28 +0000
- To: Souripriya Das <SOURIPRIYA.DAS@oracle.com>
- Cc: "<andy.seaborne@talis.com>" <andy.seaborne@talis.com>, "<public-rdf-dawg@w3.org>" <public-rdf-dawg@w3.org>
Yes, I certainly agree. - Steve Sent on the move. On 6 Jan 2010, at 00:48, Souripriya Das <SOURIPRIYA.DAS@oracle.com> wrote: > Steve, > > So as I understand both Ivan and you seemed to agree with my > thoughts (see below) regarding requiring an alias name to go with an > expression. > >> 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. >> > > Regarding changing the query example in Sec 9 to SELECT ?org (SUM(? > lprice) AS ?totalPrice) ..., we can do it afterward if it is okay > with others. > > Thanks, > - Souri. > > ----- Original Message ----- > From: steve.harris@garlik.com > To: andy.seaborne@talis.com > Cc: SOURIPRIYA.DAS@oracle.com, public-rdf-dawg@w3.org > Sent: Tuesday, January 5, 2010 7:11:28 PM GMT -05:00 US/Canada Eastern > Subject: Re: SPARQL Query 1.1 review comments > > On 5 Jan 2010, at 16:53, Andy Seaborne wrote: >> On 05/01/2010 2:33 PM, Souripriya Das wrote: > > ... > >>> 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] > > I'm not really inclined to change it at this point. Several people > have reviewed the document, so I'd rather not change things right now. > >>> 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. > > I disagree. I think it makes queries potentially harder to read and > understand, and I can't think of a sensible usecase for it. You can't > refer to it elsewhere in the query, as you don't know what it will be > called, so why project out something you can't use? > > You can't return them to a client either, as SELECT * only projects > variables that appear in the query. > > It makes sense in SQL because you can have columns called things like > “x * 3”, so engines can reliably map from expressions to column > names, > but SPARQL syntax doesn't allow that. > > - Steve >
Received on Wednesday, 6 January 2010 06:08:15 UTC