Re: SPARQL EXISTS variations

The problem with BNODE() is that it is a different bnode that the one in the 
binding set.  Admittedly, sending a bnode through a service request is a bit 
tricky, but I imagine that there might be a reason in some cases to have bnode 
identity survive the transition.

In any case, I don't believe that BIND can be used for the OVERALL case.

peter


On 8/26/25 3:10 AM, Olaf Hartig wrote:
> On Mon, 2025-08-25 at 17:00 -0400, Peter F. Patel-Schneider wrote:
>> I believe that there is a problem with SERVICE constructs - you can't send the
>> binding sets to the remote service as a VALUES construct because you can't
>> send blank nodes correctly.
> 
> You are right, that is a problem.
> 
> An alternative to adding such VALUES clauses would be to add BIND clauses, one BIND clause per variable bound in μ_ctx.
> In this case, for each variable ?v ∈ dom(μ_ctx) for which μ_ctx(?v) is a blank node, the BIND clause would be:
> 
>   BIND( BNODE() AS ?v )
> 
> It is okay that these are fresh blank nodes because the blank nodes in μ_ctx would be disjoint from the blank nodes at
> the SPARQL endpoint anyways.
> 
> For the OVERALL variant, it would have to be a UNION of multiple blocks of BIND clauses, one block per solution mapping
> in Ω_ctx.
> 
> The only tricky bit is the case in which μ_ctx binds multiple variables to the *same* blank node; e.g., ?v1,?v2 ∈
> dom(μ_ctx) such that μ_ctx(?v1) is the same blank node as μ_ctx(?v2). I am not sure how to solve that.
> 
> -Olaf
> 
> 
>> 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 Tuesday, 26 August 2025 18:20:20 UTC