Re: Agenda 2010-10-19

On 19 Oct 2010, at 08:30, Andy Seaborne wrote:

> It would help me if we could identify the principles and requirements,
> before focusing on the definition of mechanism.  Like Greg, I see the
> mechanisms ruling out queries the user might reasonably expect.  For
> example, a FILTER using bound() can guard the SERVICE call.

indeed, we had thought about this as well... the current def is over-cautious.
the problem, if I understood Carlos and Marcelo right was that, while (e.g. with those guards you suggest)
one can generalise the notion of certainly bound, it is in general
not decidable if a variable necessarily binds a variable on all graphs, so we need to cut at some point.

I am more interested at the moment, whether the general direction... defining such a restriction that guarantees "safeness" i.e. boundedness, is the way we want to go and then leave it to the editors/a task force (Eric the chairs have agreed to add Carlos to the Fed-editors... ).

> 
> Regardless of the outcome of the syntactic or execution preconditions,
> we also need to discuss what happens if a SERVICE operation fails (e.g.
> SERVICE currently unavailable).  

yes, indeed, that is the second big issue: the current spec seems to suggest that a 
single failed service call invalidates the whole query (at least, that was my reading)
this is worrying me...

> Maybe the way we handle this might
> cover how we handle unbound service references.

... maybe.

Axel


>         Andy
> 
> On 18/10/10 18:19, Gregory Williams wrote:
> > On Oct 18, 2010, at 10:23 AM, Carlos Buil Aranda wrote:
> >
> >> Hi all,
> >>
> >> please, find in the previous URL [1] the work I did together with Axel and Marcelo Arenas regarding variables which are certainly bound or not. A new concept of service-safe (whether a SERVICE ?X P is safe for execution, i.e. ?X is bounded), as Axel said.
> >>
> >> Carlos
> >>
> >> [1] http://www.w3.org/2009/sparql/wiki/Certainly_bound
> >
> > Carlos,
> >
> > I have a few comments on your "certainly bound" work.
> >
> > "* P = SERVICE t { P1 } and either t is a IRI and ?X is strongly bound in P1"
> > I'm not sure what the second branch of the "either" is here. Was there meant to be more?
> >
> > "* P = P1 BINDINGS ?X1 ... ?Xn { BindingValues } and ?X is either strongly bound within P1 or ?X = ?Xi and UNBOUND is not a possible value for a ?Xi in BindingValues."
> > What does "possible value" mean here? Does this eliminate the possibility of stream parsing BINDINGS clauses?
> >
> > "* P = GRAPH t { P1 } and ?X is strongly bound in P1"
> > I believe this should also have an option for cases where t = ?X.
> >
> >
> > After reading the "service-safeness" definition, I'm not sure it really captures what you want:
> >
> > """
> > Let P be a graph pattern. P is service-safe if for every subpattern P1 of P such that P1 = SERVICE ?X P2 it hold that
> >
> >       • there exists a subpattern P3 of P such that P1 is a subpattern of P3 and ?X is strongly bound in P3.
> >       • P2 is service-safe.
> > """
> >
> > The biggest thing that stands out to me in this definition is that I think this means that a pattern would be considered service-safe if ?x is strongly bound in P2 (inside the SERVICE pattern), and therefore strongly bound in P1 (the SERVICE) and in P3 (the group containing the SERVICE). This will leave ?x unbound at the point of execution of P1 if ?X is not strongly bound in a subpattern of P3 that *is not* P1.
> >
> > Moreover, I'm worried that trying too hard to specify these concepts of "strongly bound" and "service-safeness" will lead to legitimate queries being rejected because they are considered service-unsafe. For example, I think this should be a valid pattern (modulo the syntax of the BIND operator) but would be considered service-unsafe:
> >
> > SELECT * WHERE {
> >       {} OPTIONAL {<foo>  ns1:endpoint ?endpoint }
> >       OPTIONAL {<foo>  ns2:sparqlEndpoint ?endpoint }
> >       OPTIONAL { BIND(?endpoint AS<http://default/endpoint>) }
> >       SERVICE ?endpoint { ... }
> > }
> >
> > I think (but not completely sure) that this query could be rewritten by duplicating the SERVICE block inside each of the OPTIONAL branches. However, if that is in fact an equivalent rewriting, I'm not sure I want two semantically equivalent queries to be treated differently because the query engine/optimizer can't tell that they're equivalent.
> >
> > thanks,
> > .greg
> >
> >
>

Received on Tuesday, 19 October 2010 12:25:50 UTC