Re: SPARQL EXISTS variations

Also mostly to EXISTS TF members:

As far as I can tell, all that is required to do values injection (of any 
kind) is to have the (set of) injected binding set(s) incorporated into the 
result of the first construct of the translation of a GroupGraphPattern.  Once 
that is done the (set of) binding set(s) are available throughout the 
translation of the GroupGraphPattern.  So why not do this instead of having 
the (set of) injected binding set(s) joined into each BGP?  This might be 
easier to understand than having the values injection potentially affect 
multiple components of the translation of GroupGraphPattern.

Further, given that the translation of GroupGraphPattern (before 
simplification) always starts with a placeholder empty basic graph pattern it 
would be possible to replace this pattern with a special construct that 
instead of just producing a single empty binding set instead produced the (set 
of) injected binding set(s).

peter


On 8/24/25 2:54 PM, Olaf Hartig wrote:
> Hi EXISTS TF members,
> 
> I have updated my document after last Friday's discussion.
> 
> https://gist.github.com/hartig/3fffc7a02f3e0411158298e313b4c9c2
> 
> Most importantly, I have added a detailed discussion of all cases
> possible for the pattern within an EXISTS expression---see the section
> called "Why is a similar change not needed for the other cases?"
> 
> I have also tried to add the document into the repo [1], but somehow
> the CI run of the corresponding PR failed. Until this is fixed, the
> link above is the most recent version of the document.
> 
> -Olaf
> 
> [1] https://github.com/w3c/sparql-query/pull/270
> 
> 
> On Fri, 2025-08-22 at 11:03 +0000, Olaf Hartig wrote:
>> Hi,
>>
>> As the different variations were mentioned only informally in Peter's
>> email, I wanted to convince myself that we can
>> also define them formally in the spec. For the DEEP INJECTION
>> variations it was not immediately clear to me how this
>> could be done; especially not for the OVERALL-variant of DEEP
>> INJECTION.
>>
>> I found a way to do it (based on an idea that Andy mentioned during
>> the last TF meeting), and wrote a short document to
>> describe the exact changes that are needed:
>>
>> https://gist.github.com/hartig/3fffc7a02f3e0411158298e313b4c9c2
>>
>>
>> Best,
>> Olaf
>>
>>
>> On Thu, 2025-08-21 at 10:09 +0000, Olaf Hartig wrote:
>>> On Thu, 2025-08-21 at 03:17 +0200, James Anderson wrote:
>>>> On 20. Aug 2025, at 22:30, Andy Seaborne <andy@apache.org> wrote:
>>>>> On 16/08/2025 15:45, Peter F. Patel-Schneider wrote:
>>>>>> There was again discussion in the SPARQL EXISTS task force on
>>>>>> different solutions to the SPARQL EXISTS
>>>>>> problems.
>>>>>> The solutions amount to, roughly:
>>>>>> Simple LEFTJOIN, where no bindings from outside the EXISTS
>>>>>> affect the pattern inside.
>>>>>
>>>>> SEMIJOIN?
>>>>
>>>> is it not the case that, where no variable from the solution is
>>>> free in the exists pattern, that pattern reduces to
>>>> a
>>>> boolean constant value which depends only on the state of the
>>>> target graph?
>>>
>>> What do you mean with a variable being "free in the exists
>>> pattern"?
>>>
>>> I agree with Andy, it is a SEMIJOIN.
>>>
>>> @Peter, thanks for this great summary! I agree with your believe
>>> that ONCE versus OVERALL is relevant only for DEEP
>>> INJECTION.
>>>
>>> -Olaf
>>>
>>>
>>>>>
>>>>>> Values injection at the beginning of the pattern (SHALLOW
>>>>>> INJECTION).
>>>>>> Values injection inside the pattern (DEEP INJECTION), with
>>>>>> two variations
>>>>>> values projected out in sub-SELECTs are not affected
>>>>>> (PROJECTION) and
>>>>>> values projected out in sub-SELECTs are affected.
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---
>>>> james anderson | james@dydra.com |
>>>> https://dydra.com/
>>>>
>>>>
>>>>
>>>
>>
>

Received on Monday, 25 August 2025 19:37:21 UTC