- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 27 Aug 2025 12:07:43 -0400
- To: public-rdf-star-wg@w3.org
I created https://github.com/w3c/sparql-query/issues/275 for the interaction between deep injection and SERVICE. peter On 8/27/25 2:28 AM, 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? > > 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 16:07:54 UTC