Re: agenda for tomorrow...

On 07/12/2009 17:57, Axel Polleres wrote:
> ... will be sent out later tonite:

Sorry for this very rushed email but I am unable to spend time on 
SPARQL-WG tomorrow morning and anyway that would be too late for many 
people to have had a chance to catch up.

> Essentially, I plan to discuss the issues not covered last time
> * Do aggregate functions need to be set off syntactically?

Steve sends his regrets:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0571.html

> * Scope of alias variables

ISSUE-39

Nearby: ISSUE-41, ISSUE-12

Rather than a general discussion, can we start with a strawman:

Discussion emails:

http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0411.html
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0414.html

http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0418.html

http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0423.html
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0425.html
   (NB typo in that message)

Strawman:

Expressions do not have side-effects.

Legal:
# ?C can be used in a expression to the right,
# but not left, of it's definition.
SELECT (count(*) AS ?C)  (?Num/?C AS ?X)

Legal:
# 2009OctDec/0414.html
# HAVING, and ORDER BY, can reference a project variable.
select ?x count(?doc) as ?count where {
?x :hasCreated ?doc
}
group by ?x
having (?count > 10)

This one crosses aggregates and select expressions so is not in [1] and 
complicates Step 2 and Step 3 of modifier translation but they are 
already needing reworking anyway so that aggregates can be used in HAVING:

  having (count(?doc) > 10)

In outline, the translation is:

SELECT covers two operators: extend and project. Put the "extend" 
operations as in [1] immediate around the group (just after the algebra 
for GROUP BY and aggregate calculation and just before HAVING) and the 
projection outside the HAVING.  They are already in this order in [1] - 
it's just extending it to HAVING.

pattern => group inc aggregate calculation =>
    extends => having => order by => project =>
      distinct => reduced => offset/limit

With the SELECT expressions currently, it's no possible to introduce a 
variable then project it away.

Illegal:
# Can't use a variable introduced  in a SELECT expression inside the 
SELECTs pattern.

SELECT (?x+1 AS ?y)  { ... ?y ... }
is illegal scoping (see [1]) and is a static syntax check.

	Andy

> plus (time allowed)
> * Andy's proposal for SELECT expressions [1]

ACTION-134

I propose

SELECT ( _:b1 AS ?blank )

is not legal in the grammar, that is blank nodes can not be used in 
expressions for select-expressions (which is good ebcause they are not 
legal in expressions in FILTER currently.

	Andy

>
> details to follow, apologies
>
> Axel
>
>
> 1. http://www.w3.org/2009/sparql/docs/query-1.1/select-expr-defs-1-1.html

[2]
http://www.w3.org/2005/10/Process-20051014/policies.html#GeneralMeetings

Received on Monday, 7 December 2009 18:53:34 UTC