Re: definition of "potentially bound" variable

This was asked by Carlos [1]


Concrete example:

SELECT *
{ ?s <p> ?x }
BINDINGS ?x ?y { (1 2) (3 4) (5 6) }

Personally, I'd include ?x and ?y in the projectable variables and in *. 
for whichever definition of BINDINGS we adopt.  It seems useful to 
return the info so which rows in the answer correspond to which bindings 
can be determined.

	Andy

[1]
http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0369.html

On 14/09/10 11:27, Axel Polleres wrote:
> p.s.: as for BINDINGS, it is not clear to me entirely whether BINDINGS can introduce or just constrain solutions, I was kind of assuming the latter?
> Can someone with a better grasp on fed-query shed more light on me, please?
>
> Axel
>
> On 14 Sep 2010, at 11:15, Axel Polleres wrote:
>
>>
>> On 14 Sep 2010, at 10:44, Andy Seaborne wrote:
>>
>>>
>>>
>>> On 14/09/10 09:58, Axel Polleres wrote:
>>>> As for ACTION-304 I started a formal definition of "potentially bound" variable at
>>>>
>>>> http://www.w3.org/2009/sparql/wiki/Potentially_bound
>>>>
>>>> this is not finished, but just to get the direction clear, based on that we can hopefully redefine "*".
>>>
>>> Added MINUS (only the LHS),
>>
>> makes sense.
>>
>>> SERVICE
>>
>> As for SERVICE ?v don't we need the variable to be bound somewhere else, i.e. if the variable only appears here, can it really be bound?
>>
>>> and GROUP BY (assuming name
>>> introduction in GROUP BY)
>>
>> I changed this to
>>
>> { P1 } GROUP BY ...
>>
>> Assuming that syntactically, the GROUP BY claus alone is not a GRAPH
>> Pattern.
>>
>> I also added HAVING.
>>
>>>
>>> The other definitions need to work with GROUP BY which hides the non-key
>>> variables variables.  To do this, it would seem easier to define the
>>> concept recursively, not declaratively.
>>
>> my idea was to define it recusrively over the syntax
>>
>> best,
>> Axel
>>
>>
>>>
>>> BINDINGS?
>>>
>>>         Andy
>>>
>>>
>>
>

Received on Tuesday, 14 September 2010 10:59:51 UTC