Re: SPARQL EXISTS variations

On 27/08/2025 07:28, Olaf Hartig wrote:
> Hi Peter,
> 
> Okay, if SERVICE cannot be supported in the way outlined in my document, do you have any other proposal how it can be
> supported?

It is only blank nodes. The restriction could be that blank nodes 
(including in triple terms) are not supported.

SERVICE SILENT gives control over what to do (ignore or error).

     Andy

> 
> If we don't find a way, we may have to disallow SERVICE clauses inside the pattern of an EXISTS expression.
> 
> -Olaf
> 
> 
> On Tue, 2025-08-26 at 14:20 -0400, Peter F. Patel-Schneider wrote:
>> 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 Wednesday, 27 August 2025 14:01:17 UTC