Re: SPARQL EXISTS variations

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 07:10:31 UTC