Add tests to document current definition of EXISTS

[pfps]

Pull request to add these tests to the SPARQL test repository in the EXISTS section

[gkellogg]

See issue #42 for discussion.

[kasei]

The :existsScope02 test is defined as a QueryEvaluationTest, but does not define an mf:result. The comments on the test indicate that this is an undefined behavior. For this to be a valid (and meaningful) test, however, it either needs to be a negative test, or have an mf:result value.

[lisp]

i was wondering about this, but did not find a clear indication of how to classify negative evaluation tests of this sort, just negative syntax tests or evaluation test, such as type promotion tests, which did not produce some other specific result.

[lisp]

nb. the pfps corrections, above, should now be in the pfps-sparql-exists branch, which has been created for this issue.

[kasei]

That is because I don't believe there are any other cases where SPARQL is defined in such a way that you would expect an error that isn't a syntax error. Run-time errors are generally caught and end up producing a false effective boolean value or result in a variable not being bound.

My opinion on this is that while these tests are useful to identify places where the spec is undefined or poorly specified, it would be a mistake to have them as part of the official test suite because they don't capture the intended semantics.

[lisp]

recording limits to the language definition can be useful, in itself.

the other alternative is to define the results which they should produce.
one way to interpret them is that they follow from one reading of the recommendation, under which the behaviour is to produce a run-time error.
there are interpretations, following one of which the tests produce results.

[pfps]

This is a syntactically-valid piece of SPARQL code, but its evaluation does
something that can be considered to hit the explicitly undefined clause in the
definition of Extend.

Definition: Extend

Let μ be a solution mapping, Ω a multiset of solution mappings, var a variable
and expr be an expression, then we define:
Extend(μ, var, expr) = μ ∪ { (var,value) | var not in dom(μ) and value = expr(μ) }
Extend(μ, var, expr) = μ if var not in dom(μ) and expr(μ) is an error
Extend is undefined when var in dom(μ).
Extend(Ω, var, expr) = { Extend(μ, var, expr) | μ in Ω }

So what is the test supposed to look like?

One option would be to say that some sort of run-time exception is supposed to
be raised, but can the test setup say that?

Another option would be to say that implementations are free to do whatever
they want to do, but can the test setup say that?

A third option would be to say that trying to evaluate Extend when its second
argument is not a variable is supposed to raise a run-time exception, but how
can this be stated in the test setup?

What I did was to try to push through all the tests to some sort of result
from the SPARQL algebra evaluation, even when that evaluation was doing
something suspicious, except in this particular example, where the evaluation
hits an explicit "undefined".

peter

On 06/20/2016 08:53 AM, Gregory Todd Williams wrote:

The :existsScope02 test is defined as a QueryEvaluationTest, but does not
define an |mf:result|. The comments on the test indicate that this is an
undefined behavior. For this to be a valid (and meaningful) test, however, it
either needs to be a negative test, or have an |mf:result| value.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#43 (comment), or mute the
thread
https://github.com/notifications/unsubscribe/AGT8ez44xjmDtIZs2I2oEtyiYl6bNsYcks5qNreSgaJpZM4I5Dd1.

[kasei]

@pfps,

I believe this would be the first test case to indicate an expected runtime exception, so we'd have to create new manifest terms to describe that.

If implementations are free to do whatever they want, I don't think it belongs in the test suite (what would the test definition say is the expected result?). My understanding is that the test suite helps validate the language features that have expected behavior. For example, we can test that a RAND() returns a number in the range [0,1), but can't test that it returns a specific value. Similarly, you could have a test that asserts that an Extend() as described above is syntactically valid (positive syntax test) or syntactically invalid (negative syntax test). But if evaluation might return results or raise an error, depending on the implementation, I don't think that's appropriate to try to encode in a test (nor do I think that would be a good definition for the spec to adopt).

I would think that your third option could be considered a negative syntax test, as variable scoping rules should allow syntactic determination that at the point of filter evaluation, and Extend within an Exists may be subject to substitution. I think leaving that as a runtime exception and having the error be data-dependent could be overly confusing.

Of the three cases, I think I'd be most happy trying to find a definition that produces expected results without runtime errors. That might include syntactic restrictions within an EXISTS pattern, and almost certainly involves revising the definition of substitute().

[pfps]

On 06/20/2016 09:10 AM, Gregory Todd Williams wrote:

That is because I don't believe there are any other cases where SPARQL is
defined in such a way that you would expect an error that isn't a syntax
error. Run-time errors are generally caught and end up producing a false
effective boolean value or result in a variable not being bound.

My opinion on this is that while these tests are useful to identify places
where the spec is undefined or poorly specified, it would be a mistake to have
them as part of the official test suite because they don't capture the
intended semantics.

What is the intended semantics of SPARQL 1.1 Query? There isn't an
appropriate working group to ask at this time.

The problem is that the SPARQL 1.1 Query specification
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/ says a bunch of things
that are either ill-formed or are not carried through in implementations. A
user of SPARQL is then in the situation where SPARQL implementations do not
conform with the definition and don't even conform with each other. And this
happens for quite simple and natural SPARQL queries. This is a bad thing.

So what to do? The approach up to now has been to add errata suggestions to
https://www.w3.org/2013/sparql-errata#sparql11-query.

Indeed there is an errata suggestion "errata-query-8" about one aspect of
EXISTS. Unfortunately this is for a place where SPARQL implementations
diverge. So there is now the SPARQL specification, which says one thing, and
this errata suggestion, which says another, and implementations that go both
ways. As well, the suggested remedy doesn't work right. Not much of an
improvement.

There is also "errata-query-10" which talks about how substitute handles
VALUES clauses. This errata isn't much help at all because it doesn't say
what should happen.

My suggestion is that these tests be approved, as documenting the defined
behaviour in https://www.w3.org/TR/2013/REC-sparql11-query-20130321/ and then
that the appropriate community (and I think that this is the appropriate
community) gets together and make community-supported errata to SPARQL 1.1
query that result in EXISTS being better-defined. Hopefully the SPARQL
vendors will be involved in this discussion and will update their
implementations to match the new definition, if necessary. At that point the
tests can be changed to reflect these errata.

If I'm being even more hopeful, I would also hope that this method of fixing
up problems in W3C recommendations would become something officially blessed
by the W3C. One ongoing problem with W3C recommendations is that it is hard
to get problems in them fixed.

Peter F. Patel-Schneider
Nuance Communications

[lisp]

On 2016-06-20, at 18:23, Peter F. Patel-Schneider [email protected] wrote:

[…]

So what is the test supposed to look like?

One option would be to say that some sort of run-time exception is supposed to
be raised, but can the test setup say that?

we have already had to work around this limitation for tests in which, for instance, the suite permits undefined variables, but we do not.
the approach has been to add a feature to indicate the test requires the processor to tolerate undefined variables and interpret that feature in our harness to indicate the result will be an http 400.
this gets us to test results, but is not workable solution, generally, at scale: the feature combination would become unmaintainable.

Another option would be to say that implementations are free to do whatever
they want to do, but can the test setup say that?

or, perhaps, to define a single result.

What I did was to try to push through all the tests to some sort of result
from the SPARQL algebra evaluation, even when that evaluation was doing
something suspicious, except in this particular example, where the evaluation
hits an explicit "undefined”.

i changed our harness implementation to interpret that no result indicates a 400.
the test suite documentation would have to change to indicate something of this form and/or to modify the test classes to accommodate something like this.

[kasei]

@pfps,

What is the intended semantics of SPARQL 1.1 Query? There isn't an appropriate working group to ask at this time.

Agreed. As I said, this is only my opinion. However, I can at least tell you that as former member of the SPARQL WG (and a proponent of the EXISTS feature, though not the eventual editor of the text), your proposed tests and the spec text as written certainly aren't the semantics I had intended.

[pfps]

On 06/20/2016 09:41 AM, Gregory Todd Williams wrote:

@pfps https://github.com/pfps,

I believe this would be the first test case to indicate an expected runtime
exception, so we'd have to create new manifest terms to describe that.

If implementations are free to do whatever they want, I don't think it belongs
in the test suite (what would the test definition say is the expected
result?). My understanding is that the test suite helps validate the language
features that have expected behavior. For example, we can test that a RAND()
returns a number in the range [0,1), but can't test that it returns a specific
value. Similarly, you could have a test that asserts that an Extend() as
described above is syntactically valid (positive syntax test) or syntactically
invalid (negative syntax test). But if evaluation might return results /or/
raise an error, depending on the implementation, I don't think that's
appropriate to try to encode in a test (nor do I think that would be a good
definition for the spec to adopt).

I would think that your third option could be considered a negative syntax
test, as variable scoping rules should allow syntactic determination that at
the point of filter evaluation, and Extend within an Exists may be subject to
substitution. I think leaving that as a runtime exception and having the error
be data-dependent could be overly confusing.

Of the three cases, I think I'd be most happy trying to find a definition that
produces expected results without runtime errors. That might include syntactic
restrictions within an EXISTS pattern, and almost certainly involves revising
the definition of substitute().

Right now this test is valid syntax, so a negative syntax test is not
appropriate. My suggestion is that this should be invalid syntax, so
eventually the test would be changed to that. However, that's not the current
situation in the spec, nor is it the current situation in virtuoso.

It is actually quite easy to come up with a definition of EXISTS that doesn't
cause semantic problems in the algebra. Only two changes are needed:
1/ make BIND to variables carried through FILTER EXISTS syntactically illegal
2/ replace substitute with injection of solution sequences into the EXISTS
argument
This does change a few things.

peter

[pfps]

On 06/20/2016 09:50 AM, Gregory Todd Williams wrote:

@pfps https://github.com/pfps,

What is the intended semantics of SPARQL 1.1 Query? There isn't an
appropriate working group to ask at this time.

Agreed. As I said, this is only my opinion. However, I can at least tell you
that as former member of the SPARQL WG (and a proponent of the EXISTS feature,
though not the eventual editor of the text), your proposed tests and the spec
text as written certainly aren't the semantics I had intended.

As a user of SPARQL, that doesn't give me much comfort.

The problems with EXISTS have been known for at least two years. SPARQL
implementors must have each had to wrestle with how their implementation will
diverge from the specification. I had hoped to easily find a record of these
efforts, even if they had been found after the working group disbanded.

There is a new W3C recommendation in development (SHACL) that has a large
basis in this part of SPARQL so the time to get this fixed is now.

peter

[kasei]

@pfps,

Your injection proposal is to inject the solution sequence at the top-level of the exists pattern? If so, I believe there would be a class of queries made impossible that EXISTS was meant to allow.

[kasei]

There is a new W3C recommendation in development (SHACL) that has a large basis in this part of SPARQL so the time to get this fixed is now.

How might we get it fixed now without a newly-chartered WG?

[pfps]

On 06/20/2016 09:57 AM, Gregory Todd Williams wrote:

@pfps https://github.com/pfps,

Your injection proposal is to inject the solution sequence at the top-level of
the exists pattern? If so, I believe there would be a class of queries made
impossible that EXISTS was meant to allow.

What would these be?

peter

[pfps]

On 06/20/2016 09:58 AM, Gregory Todd Williams wrote:

There is a new W3C recommendation in development (SHACL) that has a large
basis in this part of SPARQL so the time to get this fixed is now.

How might we get it fixed now without a newly-chartered WG?

That's a good question. I tried to outline how it might happen in a previous
post. Essentially it would be to have an errata that explicitly had the
weight of the SPARQL community behind it. That's not as official as
chartering a new WG, but I would hope that it would be adequate.

peter

[kasei]

What would these be?

Cases where a top-level join isn't going to give you the same semantics as having the variable bound to a term lower-down the query tree.

I don't have specific uses cases at hand, but off the top of my head:

• GRAPH ?g {} would probably be one when ?g is substituted. Very different semantics when ?g is replaced by an IRI.
• Subqueries within the exists that do any sort of aggregation would be another. Generating any sort of count inside an EXISTS based in part on a variable that is substituted cannot be replaced with a top-level join.

[pfps]

On 06/20/2016 10:04 AM, Gregory Todd Williams wrote:

What would these be?

Cases where a top-level join isn't going to give you the same semantics as
having the variable bound to a term lower-down the query tree.

I don't have specific uses cases at hand, but off the top of my head:

• |GRAPH ?g {}| would probably be one when ?g is substituted. Very different
  semantics when `?g? is replaced by an IRI.
• Subqueries within the exists that do any sort of aggregation would be
  another. Generating any sort of count inside an EXISTS based in part on a
  variable that is substituted cannot be replaced with a top-level join.

I was trying to craft examples that would show this off.

I can come up with examples that use disconnected variables, like

SELECT ?x WHERE {
?x :p ?y .
FILTER EXISTS {
SELECT ?x WHERE { ?x ?y :b } GROUP BY ?x HAVING ( COUNT(*) > 1 )
}
}

This is precisely where different implementations diverge on behaviour. My
view is that something should be done here and my suggestion is to change the
defined behaviour. It is possible to also instead inject solution sequences
into each subqueries to not change behaviour here.

However, I can't come up with examples for connected variables.

peter

[kasei]

@pfps,

By "disconnected variables" do you mean the hiding of the inner ?y by the projection? If so, you're right -- errata seem to have solved several of the cases I have run across in the past.

How about this, though?

No projection within the EXISTS. I believe the results are different between injection and substitution. Generated on the fly, though, so please let me know if I've gotten it wrong.

[pfps]

On 06/20/2016 10:44 AM, Gregory Todd Williams wrote:

@pfps https://github.com/pfps,

By "disconnected variables" do you mean the hiding of the inner |?y| by the
projection? If so, you're right -- errata seem to have solved several of the
cases I have run across in the past.

How about this, though?
[https://gist.github.com/kasei/549c827fcb1ccfd239516885ed3b09e5]

No projection within the EXISTS. I believe the results are different between
injection and substitution. Generated on the fly, though, so please let me
know if I've gotten it wrong.

I think that this has the same result.

PREFIX : http://example/
SELECT *
WHERE {
BIND("hello" AS ?x)
BIND(<not_a_graph_name.ttl> AS ?g)
FILTER(NOT EXISTS {
{
GRAPH ?g {}
} OPTIONAL {
?s ?p ?g
}
})
}

With injection, there is a solution mapping ?g to <not_a_graph_name.ttl>
The GRAPH ends up generating solution mappings for
s p g where s p g is a triple in g
None of these have g mapping to <not_a_graph_name.ttl>
so they all get removed when joined with the injection.

With substitution, GRAPH just ends up with an empty solution mapping.

peter

[lisp]

On 2016-06-20, at 19:44, Gregory Todd Williams [email protected] wrote:

@pfps https://github.com/pfps,

By "disconnected variables" do you mean the hiding of the inner ?y by the projection? If so, you're right -- errata seem to have solved several of the cases I have run across in the past.

How about this, though? [https://gist.github.com/kasei/549c827fcb1ccfd239516885ed3b09e5 https://gist.github.com/kasei/549c827fcb1ccfd239516885ed3b09e5]

No projection within the EXISTS. I believe the results are different between injection and substitution. Generated on the fly, though, so please let me know if I've gotten it wrong.

i may understand what you aim to demonstrate here, but am not sure how that query could, as it is not clear how the filter result changes the solution constitution, rather than just determining that there is either one solution or none.

[kasei]

Hmm... yeah, I think that example isn't right. I think I made a mistake in evaluating the proposed injection semantics. I've got to get back to work, so will try to circle back to this as soon as I can allocate more time.

[kasei]

The manifest seems to have some case issues. For example, the manifest list using :existsSubquery01 but the test definition using :existsSubQuery01.

[pfps]

[off-list]

It appears that your message was somehow mangled.

peter

On 06/20/2016 12:21 PM, Gregory Todd Williams wrote:

The manifest seems to have some case issues. For example, the manifest list
using but the test definition using .

—

[pfps]

On 06/20/2016 11:18 AM, Gregory Todd Williams wrote:

Hmm... yeah, I think that example isn't right. I think I made a mistake in
evaluating the proposed injection semantics. I've got to get back to work, so
will try to circle back to this as soon as I can allocate more time.

Injection is different from substitution, but I think only in cases where
substitution by itself is problematic.

Consider
SELECT ?x WHERE {
BIND ( "a" AS ?x )
FILTER EXISTS { FILTER BOUND(?x) }
}
Injection gives one solution while substitution gives none.

I would argue that the correct answer is the injection one even though that
goes against the SPARQL specification.

Peter F. Patel-Schneider
Nuance Communications

[kasei]

I've fixed the manifest case typos in kasei/rdf-tests@4fc5080 (not sure how I can submit a PR to an already in-flight PR).

[pfps]

I did it on my copy (existsSubQuery -> existsSubquery) and also put all the
tests in the mf:entries list. As I said, I don't have a test harness so this
was all done by hand.

peter

On 06/20/2016 06:43 PM, Gregory Todd Williams wrote:

I've fixed the manifest case typos in kasei/rdf-tests@4fc5080
kasei@4fc5080 (not sure how I can submit
a PR to an already in-flight PR).

—

[lisp]

i transcribed them to the pfps-... branch and pushed them.

[lisp]

thank you for analysis.text
its accounts of the intended interpretations of the respective tests reinforce my impression that the source of these issues is, to mirror a polemic characterisation, a "broken" understanding of "substitute".

as noted elsewhere, the argument behind the current issue follows from a definition of "substitute" which requires that the implementation conflate lexical terms, abstract syntax and run-time state.
nothing in the recommendation requires this.
there is even a passage in the recommendation which suggests that the authors' understanding of the word "substitute" contradicts a naive definition.

as a thought experiment, reconsider the tests with a notion of "substitute" which is consistent with that which is required in order that the paragraph which leads section two make any sense at all.
that is, consider an interpretation in which there are variable bindings which affect the interpretation of variable references rather than informing lexical transformations.

[pfps]

On 06/21/2016 04:15 PM, james anderson wrote:

thank you for analysis.text
its accounts of the intended interpretations of the respective tests reinforce
my impression that the source of these issues is, to mirror a polemic
characterisation, a "broken" understanding of "substitute".

as noted elsewhere, the argument behind the current issue follows from a
definition of "substitute" which requires that the implementation conflate
lexical terms, abstract syntax and run-time state.
nothing in the recommendation requires this.
there is even a passage in the recommendation which suggests that the authors'
understanding of the word "substitute" contradicts a naive definition.

as a thought experiment, reconsider the tests with a notion of "substitute"
which is consistent with that which is required in order that the paragraph
which leads section two make any sense at all.
that is, consider an interpretation in which there are variable bindings which
affect the interpretation of variable references rather than informing lexical
transformations.

Well, we disagree.

I see a formal definition of EXISTS and substitute that has no wiggle room for
things like
SELECT ?x WHERE { ?x :p :b . FILTER EXISTS { ?x :p :c } }
but nonetheless often comes up with a wrong answer for this on mappings of ?x
to blank nodes.

Broken.

I see a formal definition of EXISTS and substitute that has no wiggle room for
things like
SELECT ?x WHERE { ?x :p :b . FILTER EXISTS { ?x :p :b . MINUS { ?x :p :b } } }
but nonetheless generally gets a wrong answer for this.

Broken.

I see a formal definition of EXISTS and substitute that has no wiggle room for
things like
SELECT ?x WHERE { ?x :p ?y .
FILTER EXISTS { { SELECT ?x WHERE { ?x :p ?y }
GROUP BY ?x HAVING ( COUNT(*)>1 ) }
BIND ( :d AS ?z ) } }
but where implementations diverge on the answers.

Broken.

And then there are all the cases where semantic anomalies happen.

Broken.

Just because the formal definition may not match some of the introductory,
informative text in the SPARQL 1.1 Query specification doesn't make them any
less broken.

Fixing EXISTS is going to require changing the behaviour of queries that are
perfectly well defined in the SPARQL 1.1 Query specification and have no
ambiguity at all. It is not just going to require better specifying cases
that are ambiguous or not covered. Some SPARQL implementations have already
gone this route, diverging from the SPARQL specification in places where the
specification is unambiguous and well formed.

In fact this fixing has already been suggested in errata-query-8
of https://www.w3.org/2013/sparql-errata#sparql11-query, although that
suggested erratum has its own problems.

peter

[lisp]

On 2016-06-22, at 01:59, Peter F. Patel-Schneider [email protected] wrote:

On 06/21/2016 04:15 PM, james anderson wrote:

thank you for analysis.text
its accounts of the intended interpretations of the respective tests reinforce
my impression that the source of these issues is, to mirror a polemic
characterisation, a "broken" understanding of "substitute".

as noted elsewhere, the argument behind the current issue follows from a
definition of "substitute" which requires that the implementation conflate
lexical terms, abstract syntax and run-time state.
nothing in the recommendation requires this.
there is even a passage in the recommendation which suggests that the authors'
understanding of the word "substitute" contradicts a naive definition.

as a thought experiment, reconsider the tests with a notion of "substitute"
which is consistent with that which is required in order that the paragraph
which leads section two make any sense at all.
that is, consider an interpretation in which there are variable bindings which
affect the interpretation of variable references rather than informing lexical
transformations.

Well, we disagree.

I see a formal definition of EXISTS and substitute that has no wiggle room for
things like
SELECT ?x WHERE { ?x :p :b . FILTER EXISTS { ?x :p :c } }
but nonetheless often comes up with a wrong answer for this on mappings of ?x
to blank nodes.

that is because you assert a particular implementation for substitute which is not specified by the recommendation.

Broken.

by misinterpretation.

[…]

Just because the formal definition may not match some of the introductory,
informative text in the SPARQL 1.1 Query specification doesn't make them any
less broken.

i find no text in the recommendation which prescribes how the substitution is to be effected.
have i overlooked something?

[gkellogg]

@pfps, do you agree that we should close this PR pending the outcome of the CG?

[pfps]

On 07/04/2016 06:37 PM, Gregg Kellogg wrote:

@pfps https://github.com/pfps, do you agree that we should close this PR
pending the outcome of the CG?

That's a good question. Eventually this could be closed because the CG
produces tests that cover EXISTS. But is there any harm in leaving this open
while the CG does its work?

peter

[gkellogg]

No harm in leaving it open, but it will eventually be closed without merge in favor of a new PR based on the CG's recommendations.

[gkellogg]

This has been languishing, and no indication that a CG has taken this up. Closing as indicated some time ago.

[pfps]

I believe that it is inappropriate to close this MR. The tests are correct tests of the spec. They really should be added to the test suite. If that is not possible the only other appropriate thing to do is to keep the MR open to document this continuing problem with the spec.

[gkellogg]

The way this was left in July of 2016 was that it would be closed in favor of something coming out of a CG; nothing's happened since then. Feel free to reopen this, if you think something has changed, or create a new PR, but there was not consensus in the group to merge, based on my reading of the comments.

[pfps]

Indeed, which is why it should not have been closed.

[pchampin]

This was discussed during the rdf-star meeting on 26 September 2024.

View the transcript

Addressing SPARQL EXISTS errata 4

ora: Are there people fine with the current syntax?

ora: In any case, chairs will discuss this, let's move on

AndyS: [about SPARQL EXISTS] There are two proposals

AndyS: 1. substitution based on various existing errata

AndyS: 2. an other one based on ANTIJOIN. We already have MINUS. Except the behavior with disjoin domain. But outside of it it's ANTIJOIN

AndyS: On an other note, there are other things that might go to SPARQL like LATERAL that can be based on substitution. And pure form of anti join and semi join

AndyS: It's a possibility to move these additions (LATERAL, anti join...) to sparql dev

pchampin: we would add more subtly differences between operators like FILTER NOT EXISTS vs MINUS

pchampin: Your point of having multiple ways might create problems

ora: SPARQL spec spends a bit of time presenting this difference

AndyS: It was quite contentious in SPARQL 1.1

<pchampin> I'm more than happy to let the editors decide on that

AndyS: I am not aware of any outgoing opinion, I think it ends up to a choice on which way to go

tl: is it related to triple terms in any way of is it a SPARQL errata

AndyS: it has nothing to do with triple terms

tl: what is the criteria of SPARQL errata to discuss now?

tl: it's a central issue, is that the argument?

pfps: There are a bunch of problems with SPARQL, the ones with EXIST are the biggies

pfps: They end up splitting the SPARQL implementation space

pfps: The decision that has to be made is to move SPARQL EXIST toward a more database-like implementation and keep it more consistent with the existing

AndyS: The current implementation is present in SQL with correlated subqueries

pfps: if you use the semi/anti join interepretation of EXISTS you change SPARQL more than the other option

pfps: In the end people who will see and understand the differences are very few

ora: I would like to know preferences

AndyS: My preference is for substitution and applying errata (option 1)

pfps: I don't have much of a horse in this race

pfps: Idealy I would love to get more SPARQL developers on board

ora: we could talk outside of the group

ktk: I reached out to stardog but not got an input

gtw: I am not sure much value to reach out to more developers. sparql-dev has been opened for a long time

<pchampin> Tpt: I have a signicant preference for option 1; option 2 is basically equivalent to MINUS

pfps: One way to check the issue would be to pull some tests

<pfps> which PR?

<gkellogg> w3c/rdf-tests#42

<gb> Issue 42 tests to document current definition of EXISTS in SPARQL (by pfps) [SPARQL]

<gkellogg> w3c/rdf-tests#43

<gb> CLOSED Pull Request 43 Add tests to document current definition of EXISTS (by pfps)

ora: Whatever solutions we pick, someone will ask why we pick it

AndyS: picking sustitution breaks the least queries

ora: That seems to me a as good reason as any, let's make a decision

tl: I would like to ask james about it

ora: Let's vote on it next Thursday

ora: Let's do it

---