Re: federated query question

Thanks Lee, I agree with the text.

cheers,

Carlos

2011/5/24 Lee Feigenbaum <lee@thefigtrees.net>

> Carlos, I've modified this note as discussed. Please confirm if the current
> text is OK with you.
>
> thanks,
> Lee
>
>
> On 5/12/2011 12:29 PM, Carlos Buil Aranda wrote:
>
>> yes, that's the point, to suggest the implementations to use some
>> specific order not to fail when using a variable in the endpoint
>> address. If not, the correct execution of the query can't be guaranteed.
>>
>> Carlos
>>
>> 2011/5/12 Lee Feigenbaum <lee@thefigtrees.net <mailto:lee@thefigtrees.net
>> >>
>>
>>
>>    I'm reviewing the latest set of changes.
>>
>>    In the section on boundedness (2.4) there is this note:
>>
>>    """
>>    Note that this condition does not capture passing bindings between
>>    SERVICE pattern, e.g. in
>>      { ?X :p :o SERVICE ?X { ?Y :p :o } SERVICE ?Y { ?Z :p :o } },
>>    SERVICE ?Y {...} is not service-safe, since ?Y is not strongly
>>    bounded here. In order to capture the previous case, either SERVICE
>>    semantics have to be order-dependent, or the engine has to determine
>>    an implicit order of SERVICE calls that guarantees passing binding
>>    in the right-order:
>>      { ?X :p :o SERVICE ?Y { ?Z :p :o } SERVICE ?X { ?Y :p :o } }
>>
>>    The above query can be "emulated" with a nested SERVICE call as
>> follows:
>>
>>      { ?X :p :o SERVICE ?X { ?Y :p :o SERVICE ?Y { ?Z :p :o } } }
>>
>>    This only works if the called services support (nested) SERVICE
>>    patterns.
>>
>>    """
>>
>>    If I understand correctly, the intent of our current effort at
>>    including the notion of strongly bound is to prohibit a query that
>>    uses SERVICE like this. Is this correct? If so, I will change the
>>    wording to reflect this and to suggest that implementations might
>>    extend SERVICE by detecting an execution order that guarantees
>>    variables used with SERVICE are strongly bound.
>>
>>    thanks,
>>    Lee
>>
>>
>>

Received on Tuesday, 24 May 2011 12:12:08 UTC