Meeting minutes
<james> 1+
AndyS: Encrico said that the Friday Semantics TF timeslot will free up soon.
<pfps> either are fine for me
<tl> makes no difference to me
AndyS: I need to confirm this with Enrico.
… Some TFs do work on call time. I think we can do most discussion on GitHub issues.
… It's easier for people following along by following GH Issues.
… We also need to settle on organizer/chair for this TF.
james: I feel somewhat responsible, but I don't feel competent to run a meeting.
AndyS: I'm happy to keep organizing
james: I have observed that the WG intended to decide on somthing that I believe would have been a bad idea.
… I don't think the charter allows us to do some of the work that's been proposed.
… With an extended charter, it's not as bad. But, there's value in having people look at this specific issue to determine the future of SPARQL.
… My concern was discussed with the council, and I said it would be possible if you didn't instantiate graphs, but I didn't think the group was ready to do this work.
… I'm also concerned that there are approaches that require a new operator (Lateral Join),
… I'd like to see if we can solve EXISTS with existing mechanisms and includes a dynamic-binding approach for parameterized queries.
<AndyS> w3c/
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised]
olaf: I didn't have time to read all the documentation before the meeting, but I've read through many times before.
… I recall that the proposed solution (which AndyS proposed) seems like a useful extension point. This means we don't need to add additional features.
tl: I'm not sure what the TF topic is; if it's just EXISTS, I may drop out.
… If the topic is general SPARQL errata, I'd like to see us work on named-graph issues.
pfps: I thought the TF scope was explicit, so I don't know why people think there should be "creep".
… There's a well-identified set of deficiencies in the SPARQL standards that give rise to non-sensical results.
… In other cases, there have been divergences.
… The remit of this TF should be to alleviate those situations.
… Some of the solutions are not problematic.
… I think either proposed direction is acceptable. Adding new features could be considered afterwards.
… It seems "unoptimized" to discard a chance to fix glaring problems in SPARQL.
Tpt: I think Olaf summarized my thoughts. I think SEP-007 is the right approach.
gkellogg: Main WG is behind on tests
… develop tests along with spec text
AndyS: The charter says "errata" not new features. They become possible when the WG goes into maintenance mode.
… The charter of this WG is to set that up, and do errata.
… tl discussed keywords for new features. Some of those are out of scope.
… There are a few that will need some work, but not as much work as EXISTS.
james: I agree that this particular erratum should be resolved.
… We can address the core by changing the language to not instantiate ...
… Some implementations treat blank nodes as values not variables.
… We have an implementation that agrees with the suggested approach, with some distinctions for bindings and substitution. It doesn't work, which is why I objected.
… Given a large solution set, it can take a lot of time. This means you need a different mechanism to join different pieces together.
… Lateral join is an approach that can work.
… We have had an analogous solution working for a decade, but it does not perform adequately, so I'm looking for an alternative.
AndyS: Could you write an item on the issue?
james: The solution is to change the interpretation so that it doesn't imply that results be instantiated.
AndyS: SQL required correlated sub-queries. It then executes that query given the context at the time.
… There's been discussion in the SQL community about extending that within the standard. That's resulted in some organizations opposing it.
… The Lateral Join work has emerged from that work in SQL.
james: I wrote an essay on how to do this as a lateral join, which involves re-writing the query.
AndyS: The role of the spec is to define the right outputs, not necessarily the way you do it.
… That's why we have tests.
… There are a couple of different approaches to solving the issue.
pfps: At one point there were tests that showed the differences between what the currently does and the different approaches.
… It might be worthwhile to grab those tests early.
… Some of them were from me, but there are others too.
… There are differences between james wants EXISTS to work and what SEP-007 does.
james: It should be specified using a correlated sub-query.
pfps: I thought there were examples in different outputs from the different approaches.
… There's a difference between the two approaches (correlated and non-correlated joins).
AndyS: Does this related to w3c/sparql-query#156?
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised]
Tpt: Is the un-correlated option ...
AndyS: MINUS is a less pure anti-join.
… If there are differences in the way people approach EXISTS. If there's one that people think is correct but produces different results, we should know that.
pfps: It was surprising to me that SPARQL implementers didn't seem to care about diverging results.
AndyS: If you avoid areas where it blows up, I'm not aware of ambiguities.
pfps: Not ambiguities, but different answers. It relates to disconnected variables.
… If you have an EXISTS with multiple sub-queries, one of which contains a variable which is not projected up, it can cause name clashes.
… I think there was a plurality of results, and some that did something different.
james: My reaction is that I would think that the language would benefit from a unified definition of dynamic binding, which would benefit several areas.
… This could also be used to standardized query parameterization.
… A dynamic binding is a mechanism where one establishes that a value is available during execution.
… Then the extend of the form including the variable completes, it no longer is in effect.
… It's the same kind of thing that could be used for global-binding for query parameters. The question is, what is the scope of these bindings?
AndyS: We need to collect some information and put on the issue.
… Aiming for a regular Friday slot would work better for the group; I'll contact Enrico.
… The SHACL group is also interested in the outcome; it's not quite the same situation.
james: It would be nice to have pointers to some cases where this matters.
AndyS: SHACL substitutes arbitrary points within a query. You might need the concept of a path as a term.
james: I'm glad people want to spend time on this issue.