Re: Agenda 2010-10-19

  On 19/10/2010 8: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.
I agree, we should look more at the definition since it is in early 
stages, and we should prevent unwanted behaviour. My idea was to provide 
formal syntax to a sentence that was unclear to me. How it is 
implemented is also important to me, and discussing way about how to 
prevent unbounded values is of much help.
>
> 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).  Maybe the way we handle this 
> might cover how we handle unbound service references.
Yes, I think this would be a very important discussion.

cheers,

Carlos
>
>     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 13:45:27 UTC