- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Tue, 19 Jul 2011 17:27:52 -0400
- To: Carlos Buil Aranda <cbuil@fi.upm.es>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On Jul 19, 2011, at 5:02 PM, Carlos Buil Aranda wrote: > just summarizing a bit, the main concern is the use of variables in SERVICE. The problem relies in the specification of the semantics and the boundedness condition which suggests an order for executing the query. The problem is first, the way of defining the execution of SERVICE VAR, which using the current join semantics is wrong because it is not possible to evaluate Join(G, Service(VAR, G, Transform(P), SilentOp)) because VAR still hasn't a value. Following this, the boundedness condition, which has to be completed for all the SPARQL 1.1 operators. Am I right? Thanks Carlos. Yes, I think this is a good summary of the biggest issues. > So, the possible solutions are: > - For the SERVICE VAR semantics > - add a new operation that could allow the evaluation (operation which wouldn't be bottom-up) > - define its whole semantics in a new way > - For the boundedness restriction > - specify all cases: it may take a bit long > - remove it? I do not think this is a good idea, how do we specify then that a variable is bound (which is needed for the evaluation semantics of SERVICE VAR)? It might be needed for the evaluation semantics, but I don't think the current text connects the two. There is no mention of strongly bounded variables or service safeness in the "Definition: Evaluation of a Service Pattern" section. thanks, .greg
Received on Tuesday, 19 July 2011 21:28:48 UTC