Meeting minutes
Scribe?
<AndyS> will need to share scribing
Discussion and opinions and criteria issue 130
<AndyS> w3c/
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised]
AndyS: The critera are on issue 130
olaf: I go in the order creteria appear on the issue
olaf: 1st continuity: I think it makes total sense
olaf: 2nd: provide interesting features: I don't care so much about it, there is a criterion "respect the motivation of SPARQL 1.1 decision" that I find similar
Tpt: I agree, let's merge "provide interesting features" into "respect the motivation of SPARQL 1.1 decision"
AndyS: [explanation on MINUS vs EXISTS]
olaf: 3rd: "minimality": "EXIST should not require facilities that are not strictly required to it"
pfps: [author of "minimality"]: we need EXISTS but do we need to have variable renaming/deep value injection and specefic-features like it? If we can get away without it it would be better.
pfps: Given that SPARQL 1.1 has a broken EXIST, let's fix it in a way that is resonable even if it means breaking a bit more queries
pfps: Current SPARQL 1.1 EXIST has a bunch of caracteristics, some are clearly broken, some are artifacts of the way used to define it
pfps: Let's not complicate SPARQL too much just to keep aspects of the current version of EXIST
pfps: This is in conflict with changing as few things as possible
pfps: ...in terms of the outcome
pfps: For example connected variables in subselect act a certain way in the rest of SPARQL
pfps: If we have a special case for EXIST this looks like a strike against this criterion
AndyS: OPTIONAL already handles FILTER specially
<Tpt> s/pfps OPTIONAL/AndyS: OPTIONAL/
AndyS: There is no algebra operator for subselect
james: I agree with pfps criterion in general.
james: one needs to keep in mind something will be different because the SPARQL scoping rule is upward in general whereas in EXIST it is downward
james: So it is going to be different
gtw: In the SPARQL 1.1 WG we were trying to support two way of thinking about negation, the NOT EXIST side of that was in the context of FILTER
<TallTed> s|s/pfps OPTIONAL/AndyS: OPTIONAL/||
gtw: In FILTER you take the row you filter, do various replacement in the expression and see if it returns true or not
gtw: It is an other approach of understanding negation and I would be in favor of following paths that goes into this direction of understanding negation
pfps: I agree we don't want a MINUS solution but a way to inject values into the FILTER
pfps: If having the value flow into subselect to be seen in FILTER into subselect is intended, sure it's a good support. But if it's incidental...
gtw: I am not at ease with the word "flowing", it alreay get away the mental model of just doing variable substitution at the syntaxic level
AndyS: This is something we need to come back to
AndyS: let's finish the list
olaf: Next criterion: "bottom-up evaluation" I am not even sure it is possible, perhaps thinking more about it it might be possib/le
<pfps> from 1.1 "Due to the bottom-up nature of SPARQL query evaluation, the subqueries are evaluated logically first, and the results are projected up to the outer query."
AndyS: This is related on the paper on related paper to rewrite correlated subqueries as joins
olaf: The intuition is that if it allows to run the subquery only one within the filter I am in favor of that
olaf: next one, address the errata raised on SPARQL 1.1
AndyS: We have a responsibility to not address them but at least take them seriously
AndyS: It also relate to the continuity thing. If it's not an errata, it gives the intuition it's not something to change
AndyS: pfps touch it a bit with "minimality"
olaf: next one "rrefer to do all work in the pre-execution syntax to algebra stage"
AndyS: At the moment SPARQL 1.1 write it as change to the syntax inside of a for loop, if we can move this up into a single change to the algebra, it shows where optimisations can happen
AndyS: We need to discuss the relationship with SQL correlation
pfps: I agree that all these criteria are good
pfps: But it's difficult to have them all
pfps: The one "all the work on the pre-execution syntax" I don't think this contradict anything, you can always play with the solution
pfps: Any solution that modifies the algebra can be changed with a solution that does not change it
pfps: The contradiction I see is between continuity and minimality. continuity might require a more complex solution than one can do
pfps: Maybe there is a minimal solution that maintain as much continuity as possible
pfps: I read maximum continuity as "do not change any response that does not return an error in SPARQL 1.1"
pfps: minimality does not allow to produce things that are not syntacticly correct, and fixing that with deep substition violate continuity
<pfps> another definition of continuity would be to not change anything for which there is not an errata
tpt: can we tweak continuality to be "normal case" suggested by the spec?
<pfps> this is, I think, the continuity that Andy is using
pfps: w3c/
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised]
(point 2)
Tpt: my proposal is to make a first decision to not turn EXISTS into MINUS and keep some lesser version of continuity
pfps: we would just follow that aspect of SPARQL 1.1 that state that EXISTS and MINUS are different
AndyS: Let's stay on having a look at criteria at the moment, criteria are some kind of opinions
<pfps> andy? does FILTER EXISTS { { FILTER ... } } show the difference between deep and shallow injection?
james: I am very much partial to bottom up evaluation being a preferable caracteristic
james: It will likely provide evaluation efficiency
james: EXISTS with substitution does not perform very well
james: The scoping rules turn to be an open question
james: How much algebra transformation needs to happen before bottom up evaluation is doable, I don't know
james: I am uncertain to consider if the current variation are all wrong except one or possible approach variation we can take
<pfps> I have to step out for a bit
gtw: I don't see anything objectionable in the criteria
gtw: I am by default in favor of keeping EXISTS and MINUS as two different approach to negation
gtw: ... with a slight preference to minor changes that stay close with the 1.1 motivations
<pfps> I'm back
AndyS: TallTed, Is Virtuoso's SQL implementation using correlated subqueries
AndyS: The subquery one is an issue to have a look
pfps: Do we have any other proposed solution?
pfps: We have one that is essentially MINUS
pfps: SQL has this notion of correlated variable
pfps: I am going to figure out examples like FILTERs inside FILTERs
pfps: Without filters is there any visible difference between different approaches?
AndyS: I have 3 examples, one of these is "SELECT *"
AndyS: we got stuff with UNION and OPTIONAL
Tpt: we should have a look at SQL correlated subqueries, if we can make our approach close to it, it might ease SPARQL on top of SQL implementations (small plus)