Re: SPARQL EXISTS variations

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 06:29:03 UTC