Re: fed review

On 20/07/11 03:53, Carlos Buil Aranda wrote:
> any more opinions on that?

Another option is to leave the possibility open - slightly different 
from Lee's making it an error.  Or an optional feature of an optional 
feature.

It's a constraint - just like any other constraint in the language.  For 
most of them, we define via the algebra what the constraint means and we 
get exact answers for any non-fed query.

If we think of ?g ranging over all possible SPARQL endpoints (a 
theoretical device - bottom up evaluation - and say that an engine 
executes with a subset of possibilities, and of course that subset can 
be constrained by a join relationship.

	Andy

>
> thanks,
>
> Carlos
>
> 2011/7/19 Gregory Williams <greg@evilfunhouse.com
> <mailto:greg@evilfunhouse.com>>
>
>     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 Wednesday, 20 July 2011 19:02:47 UTC