Meeting minutes
<TallTed> / /// /
<TallTed> s|/ /// /| |
Scribe?
Discussion: Deep vs Shallow injection
AndyS: Goal: figure out where we are between deep vs shallow EXIST and do a poll
AndyS: [Explanation on deep vs shallow]
TallTed: Is there any sense of what each of these option delivers or fails to deliver? What can we do with one but not with the other?
AndyS: Deep is closer to the spec (the spec says "replace all the current occurences"). Shallow is closer to MINUS (for anything nested it has similar effect: evaluate then combine)
TallTed: We should get more input
AndyS: I would prefer is make a decision on it, maybe classify it as "feature as risk".
AndyS: I don't think we might get more input
james: I tried to characterize the queries where it makes a difference
<AndyS> SELECT * { ?s ?p ?o FILTER EXISTS { FILTER(?o = 10) } }
<AndyS> SELECT * { ?s ?p ?o FILTER EXISTS { {} UNION { FILTER(?o = 10) } } }
<Zakim> gtw, you wanted to mention something about using wikidata query logs in assessing
AndyS: The difference is mostly on nested FILTER
gtw: What I think it is instructive to have a look at Wikidata, Blazegraph has some bugs around EXIST. I would be careful to using those logs to guide our decision making
james: My goal is less what Blazegraph is producing but more what people try to express
james: My main concern is complexity: there are more complexity than in my customer queries
james: Currently we do dynamic bindings (effectively deep bindings)
AndyS: Jena does nearly the same. I hope that the draft of the value insertion PR is effectively that.
AndyS: ...in the same way as the dynamic environment
james: it's implicit in our implementation
AndyS: Just like Jena
gtw: I don't think customers are aware of the semantic differences, any option would not violate there expectations
AndyS: The more difficult question: did they consider MINUS vs EXIST?
<AndyS> https://
<AndyS> https://
tpt: look at the options that change the least - which is also not adding features
… forward compatibility e.g. LATERAL build on the mechanism we choose for EXISTS
… avoid "similar but different"
james: Our customer use parameterized queries which this is related to. Deep binding is closer to parameterization.
<Zakim> Tpt, you wanted to agree with james
tpt: I support james on this.
… LATERAL, parameterization, closer to spec (which substitutes in the whole pattern [scribe])
james: It is very unfortunate that Peter is not here
<TallTed> how we have handled parameterizing SPARQL in Virtuoso (starting in the third body paragraph) -- https://
AndyS: I contacted Olaf, he is neutral on the decision, he cares about having a formally correct text in the spec
AndyS: I asked Ruben too, he said he is neutral as well
james: So, the only open question is Peter
tpt: we can maybe do a poll now to get an idea of the direction, taking into account that Peter position is missing
tpt: can we do a strawpoll to see for those present?
strawpoll: Which mechanism (deep vs shallow) do you prefer at the moment? (vote D or S)
<james> D
<AndyS> s/DRAFT --//
D
<gtw> D
<TallTed> neutral (because I don't have a strong enough sense of which delivers more than the other)
D
Olaf: : neutral
Ruben: : neutral
(Olaf and Ruben had said they were not able to attend and submitted a "postal vote")
AndyS: I will check to come up with tests that present the point but don't involve subqueries
Strawpoll on Deep vs Shallow injection
AndyS: I will try to figure out what Peter's position is
<james> no holidays here
Likely regrets for the first 2 weeks of August
LHS BIND ( 123 AS ?X)
LHS BIND ( (123+?Y) AS ?X)
AndyS: next time - consider variable scope and sub-SELECT
james: My concern from Wikidata query log, there are half of the cases where EXIST expression have more than a 4 complexity
james: I will look for things with 5-6 operators as examples
james: I have no idea if they are machine or human generated or not