Re: ungrouped variables used in projections - Further implications?

On Aug 25, 2010, at 2:07 PM, Axel Polleres wrote:

>>>>   SELECT (count(*) AS ?p) { ?s ?p ?o } GROUP BY ?s
>>> ...
>>>>   SELECT (SAMPLE(?p) AS ?p) { ?s ?p ?o } GROUP BY ?s
>>> 
>>> This is seemingly (but strangely enough not quite?) in conflict with:
>>> "The new variable is introduced using the keyword AS; it must not already be potentially
>>> bound."
>>> 
>>> I'd honestly prefer somehow to strenghten this restriction to:
>>> 
>>> "The new variable is introduced using the keyword AS; it must not already occur in the WHERE clause."
>> 
>> Disagree - the GROUP example puts the inner variable out of scope.
> 
> I don't really understand? With what exactly do you disagree?
> I think we both agree that the current wording doesn't
> "The new variable is introduced using the keyword AS; it must not already be potentially bound."
> apply to your example.

Doesn't the current wording apply to the example? The GROUP BY means that ?p cannot be bound without explicitly naming an aggregate or project expression (as is done in the examples above).

>>> Funny enough, note that the original "potentially bound" formulation is problematic/imprecise already
>>> without aggregates:
>>> 
>>>  SELECT (?X as ?Y) WHERE { ?S ?P ?X OPTIONAL { ?S ?P ?Y FILTER(?Y != ?Y) } }
>>> 
>>> Obviously, there is no way that ?Y ever returns a binding by the FILTER expression...
>>> so it is not "potentially bound" and that query would be syntactically ok, according to the definition.
>>> I guess many will agree that checking static unsatisfiability of FILTER expressions would be a nightmare for parsers :-)
> 
> Any opinions on this? This actually worries me about the current  "potentially bound" wording.

Agree that "potentially bound" is probably the wrong wording as demonstrated by your optional/filter example, but I wouldn't want to see Andy's examples forbidden as they seem like reasonable cases to me.

thanks,
.greg

Received on Wednesday, 25 August 2010 18:25:15 UTC