14:07:34 <RRSAgent> RRSAgent has joined #rdf-star
14:07:38 <RRSAgent> logging to https://www.w3.org/2025/04/23-rdf-star-irc
14:07:38 <Zakim> RRSAgent, make logs Public
14:07:39 <Zakim> please title this meeting ("meeting: ..."), gkellogg
14:07:49 <gkellogg> meeting: RDF-star SPARQL TF
14:07:52 <gkellogg> chair: afs
14:07:57 <gkellogg> present+
14:08:08 <AndyS> present+
14:08:10 <tl> present+
14:08:13 <james> present+
14:09:08 <gkellogg> scribe+
14:09:32 <james> 1+
14:09:35 <gkellogg> AndyS: Encrico said that the Friday Semantics TF timeslot will free up soon.
14:09:35 <olaf> present+
14:09:44 <pfps> either are fine for me
14:09:45 <gkellogg> chair: AndyS
14:10:00 <tl> makes no difference to me
14:10:36 <gkellogg> AndyS: I need to confirm this with Enrico.
14:11:32 <gkellogg> ... Some TFs do work on call time. I think we can do most discussion on GitHub issues.
14:11:50 <gkellogg> ... It's easier for people following along by following GH Issues.
14:12:20 <Tpt> present§
14:12:31 <Tpt> present+
14:12:37 <gkellogg> ... We also need to settle on organizer/chair for this TF.
14:12:47 <Tpt> s/present§//
14:13:08 <gkellogg> james: I feel somewhat responsible, but I don't feel competent to run a meeting.
14:13:54 <gkellogg> AndyS: I'm happy to keep organizing
14:14:13 <james> q+
14:14:20 <pfps> q+
14:14:30 <gkellogg> ack james
14:15:03 <gkellogg> james: I have observed that the WG intended to decide on somthing that I believe would have been a bad idea.
14:15:25 <gkellogg> ... I don't think the charter allows us to do some of the work that's been proposed.
14:15:57 <gkellogg> ... 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.
14:16:51 <gkellogg> ... 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.
14:16:54 <pfps> q-
14:17:17 <gkellogg> ... I'm also concerned that there are approaches that require a new operator (Lateral Join),
14:17:52 <gkellogg> ... I'd like to see if we can solve EXISTS with existing mechanisms and includes a dynamic-binding approach for parameterized queries.
14:18:33 <AndyS> https://github.com/w3c/sparql-query/issues/156
14:18:34 <gb> https://github.com/w3c/sparql-query/issues/156 -> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised]
14:18:50 <gkellogg> olaf: I didn't have time to read all the documentation before the meeting, but I've read through many times before.
14:19:34 <gkellogg> ... 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.
14:20:17 <gkellogg> tl: I'm not sure what the TF topic is; if it's just EXISTS, I may drop out.
14:20:41 <gkellogg> ... If the topic is general SPARQL errata, I'd like to see us work on named-graph issues.
14:21:31 <gkellogg> pfps: I thought the TF scope was explicit, so I don't know why people think there should be "creep".
14:21:54 <gkellogg> ... There's a well-identified set of deficiencies in the SPARQL standards that give rise to non-sensical results.
14:22:13 <gkellogg> ... In other cases, there have been divergences.
14:22:30 <gkellogg> ... The remit of this TF should be to alleviate those situations.
14:22:51 <gkellogg> ... Some of the solutions are not problematic.
14:23:20 <gkellogg> ... I think either proposed direction is acceptable. Adding new features could be considered afterwards.
14:23:38 <gkellogg> ... It seems "unoptimized" to discard a chance to fix glaring problems in SPARQL.
14:24:17 <gkellogg> Tpt: I think Olaf summarized my thoughts. I think SEP-007 is the right approach.
14:24:56 <AndyS> scribe+
14:25:10 <AndyS> gkellogg: Main WG is behind on tests
14:25:27 <AndyS> ... develop tests along with spec text
14:25:41 <AndyS> scribe-
14:26:15 <gkellogg> AndyS: The charter says "errata" not new features. They become possible when the WG goes into maintenance mode.
14:26:31 <gkellogg> ... The charter of this WG is to set that up, and do errata.
14:27:19 <gkellogg> ... tl discussed keywords for new features. Some of those are out of scope.
14:28:00 <gkellogg> ... There are a few that will need some work, but not as much work as EXISTS.
14:28:16 <james> q+
14:28:42 <gkellogg> james: I agree that this particular erratum should be resolved.
14:29:03 <gkellogg> ... We can address the core by changing the language to not instantiate ...
14:29:43 <gkellogg> ... Some implementations treat blank nodes as values not variables.
14:30:52 <gkellogg> ... 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.
14:31:29 <gkellogg> ... Given a large solution set, it can take a lot of time. This means you need a different mechanism to join different pieces together.
14:31:46 <gkellogg> ... Lateral join is an approach that can work.
14:32:43 <gkellogg> ... We have had an analogous solution working for a decade, but it does not perform adequately, so I'm looking for an alternative.
14:33:10 <gkellogg> AndyS: Could you write an item on the issue?
14:34:23 <gkellogg> james: The solution is to change the interpretation so that it doesn't imply that results be instantiated.
14:35:22 <gkellogg> AndyS: SQL required correlated sub-queries. It then executes that query given the context at the time.
14:35:58 <gkellogg> ... There's been discussion in the SQL community about extending that within the standard. That's resulted in some organizations opposing it.
14:36:32 <gkellogg> ... The Lateral Join work has emerged from that work in SQL.
14:37:07 <gkellogg> james: I wrote an essay on how to do this as a lateral join, which involves re-writing the query.
14:37:40 <gkellogg> AndyS: The role of the spec is to define the right outputs, not necessarily the way you do it.
14:38:01 <gkellogg> ... That's why we have tests.
14:38:47 <gkellogg> ... There are a couple of different approaches to solving the issue.
14:39:49 <gkellogg> pfps: At one point there were tests that showed the differences between what the currently does and the different approaches.
14:40:08 <gkellogg> ... It might be worthwhile to grab those tests early.
14:40:19 <gkellogg> ... Some of them were from me, but there are others too.
14:41:03 <gkellogg> ... There are differences between james wants EXISTS to work and what SEP-007 does.
14:41:42 <gkellogg> james: It should be specified using a correlated sub-query.
14:41:58 <gkellogg> pfps: I thought there were examples in different outputs from the different approaches.
14:42:50 <gkellogg> ... There's a difference between the two approaches (correlated and non-correlated joins).
14:42:52 <Tpt> q+
14:43:19 <AndyS> ack james
14:43:21 <gkellogg> AndyS: Does this related to w3c/sparql-query#156?
14:43:21 <gb> https://github.com/w3c/sparql-query/issues/156 -> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised]
14:43:52 <gkellogg> Tpt: Is the un-correlated option ...
14:44:11 <gkellogg> AndyS: MINUS is a less pure anti-join.
14:44:40 <tl> tl has joined #rdf-star
14:44:54 <gkellogg> ... 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.
14:45:16 <gkellogg> pfps: It was surprising to me that SPARQL implementers didn't seem to care about diverging results.
14:45:38 <gkellogg> AndyS: If you avoid areas where it blows up, I'm not aware of ambiguities.
14:46:05 <gkellogg> pfps: Not ambiguities, but different answers. It relates to disconnected variables.
14:46:36 <gkellogg> ... 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.
14:47:08 <gkellogg> ... I think there was a plurality of results, and some that did something different.
14:47:24 <AndyS> q?
14:47:34 <james> q+
14:47:37 <AndyS> ack Tpt
14:47:53 <gkellogg> ack james
14:48:37 <gkellogg> 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.
14:48:53 <gkellogg> ... This could also be used to standardized query parameterization.
14:49:35 <gkellogg> ... A dynamic binding is a mechanism where one establishes that a value is available during execution.
14:49:54 <gkellogg> ... Then the extend of the form including the variable completes, it no longer is in effect.
14:50:53 <gkellogg> ... 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?
14:51:44 <gkellogg> AndyS: We need to collect some information and put on the issue.
14:52:10 <gkellogg> ... Aiming for a regular Friday slot would work better for the group; I'll contact Enrico.
14:52:32 <james> q+
14:52:41 <gkellogg> ... The SHACL group is also interested in the outcome; it's not quite the same situation.
14:53:19 <gkellogg> james: It would be nice to have pointers to some cases where this matters.
14:53:59 <gkellogg> AndyS: SHACL substitutes arbitrary points within a query. You might need the concept of a path as a term.
14:54:45 <gkellogg> james: I'm glad people want to spend time on this issue.
14:55:19 <gkellogg> zakim, end meeting
14:55:19 <Zakim> As of this point the attendees have been gkellogg, AndyS, tl, james, olaf, Tpt
14:55:21 <Zakim> RRSAgent, please draft minutes
14:55:23 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/23-rdf-star-minutes.html Zakim
14:55:30 <Zakim> I am happy to have been of service, gkellogg; please remember to excuse RRSAgent.  Goodbye
14:55:30 <Zakim> Zakim has left #rdf-star
14:55:44 <olaf> olaf has left #rdf-star
14:55:57 <gkellogg> rrsagent, bye
14:55:57 <RRSAgent> I see no action items