- 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