- From: Axel Polleres <axel.polleres@deri.org>
- Date: Tue, 14 Sep 2010 11:27:54 +0100
- To: Axel Polleres <axel.polleres@deri.org>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, "SPARQL Working Group" <public-rdf-dawg@w3.org>
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:28:29 UTC