01:05:09 gkellogg has joined #rdf-star 01:26:16 gkellogg has joined #rdf-star 01:42:35 gkellogg has joined #rdf-star 03:01:49 gkellogg has joined #rdf-star 03:12:37 gkellogg has joined #rdf-star 04:44:41 gkellogg has joined #rdf-star 05:00:34 gkellogg has joined #rdf-star 06:27:15 gkellogg has joined #rdf-star 07:51:31 gkellogg has joined #rdf-star 08:09:50 gkellogg has joined #rdf-star 08:27:27 gkellogg has joined #rdf-star 08:44:36 gkellogg has joined #rdf-star 08:51:55 RRSAgent, leave 08:51:55 I see 1 open action item saved in https://www.w3.org/2025/06/12-rdf-star-actions.rdf : 08:51:55 ACTION: pchampin to extract the "unstar" mapping from RDF-concepts [1] 08:51:55 recorded in https://www.w3.org/2025/06/12-rdf-star-irc#T16-26-28 13:55:37 RRSAgent has joined #rdf-star 13:55:37 logging to https://www.w3.org/2025/06/13-rdf-star-irc 13:55:57 zakim, this is SPARQL TF 13:55:57 got it, AndyS 13:56:30 meeting: https://www.w3.org/events/meetings/26709987-3468-402b-8c9d-d9d1a724e589/20250613T140000/ 13:56:43 agenda: https://www.w3.org/events/meetings/26709987-3468-402b-8c9d-d9d1a724e589/20250613T140000/#agenda 13:56:44 clear agenda 13:56:44 agenda+ Scribe? 13:56:44 agenda+ Discussion and opinions and criteria -> issue 130 https://github.com/w3c/sparql-query/issues/130 13:56:44 agenda+ Topic for next time 13:56:56 agenda? 13:57:11 rrsagent, please make logs public 13:57:22 rrsagent, please draft minutes 13:57:24 I have made the request to generate https://www.w3.org/2025/06/13-rdf-star-minutes.html AndyS 14:00:22 pfps has joined #rdf-star 14:12:46 gkellogg has joined #rdf-star 14:29:11 gkellogg has joined #rdf-star 14:31:30 james has joined #rdf-star 14:31:41 present+ 14:31:54 present+ 14:32:53 olaf has joined #rdf-star 14:33:55 agenda? 14:34:10 zakim, take up item 1 14:34:10 agendum 1 -- Scribe? -- taken up [from agendabot] 14:34:40 present+ 14:34:41 scribe+ 14:34:52 present+ 14:34:52 present+ 14:35:07 will need to share scribing 14:35:11 gkellogg has joined #rdf-star 14:35:13 zakim, next item 14:35:13 agendum 2 -- Discussion and opinions and criteria -> issue 130 https://github.com/w3c/sparql-query/issues/130 -- taken up [from agendabot] 14:35:40 https://github.com/w3c/sparql-query/issues/156 14:35:41 https://github.com/w3c/sparql-query/issues/156 -> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised] 14:36:15 AndyS: The critera are on issue 130 14:36:57 olaf: I go in the order creteria appear on the issue 14:36:58 present+ 14:37:12 olaf: 1st continuity: I think it makes total sense 14:38:57 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 14:39:08 TallTed has joined #rdf-star 14:39:19 Tpt: I agree, let's merge "provide interesting features" into "respect the motivation of SPARQL 1.1 decision" 14:40:08 AndyS: [explanation on MINUS vs EXISTS] 14:41:01 olaf: 3rd: "minimality": "EXIST should not require facilities that are not strictly required to it" 14:42:16 present+ 14:42:21 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. 14:42:43 q+ 14:42:52 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 14:43:30 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 14:43:45 pfps: Let's not complicate SPARQL too much just to keep aspects of the current version of EXIST 14:44:06 pfps: This is in conflict with changing as few things as possible 14:44:11 I have made the request to generate https://www.w3.org/2025/06/13-rdf-star-minutes.html TallTed 14:44:23 pfps: ...in terms of the outcome 14:44:50 pfps: For example connected variables in subselect act a certain way in the rest of SPARQL 14:45:14 pfps: If we have a special case for EXIST this looks like a strike against this criterion 14:45:59 pfps: OPTIONAL already handles FILTER specially 14:46:08 s|meeting: https://www.w3.org/events/meetings/26709987-3468-402b-8c9d-d9d1a724e589/20250613T140000/|meeting: RDF & SPARQL WG, SPARQL TF | 14:46:22 s/pfps OPTIONAL/AndyS: OPTIONAL/ 14:46:29 chair: AndyS 14:46:52 q+ 14:47:05 AndyS: There is no algebra operator for subselect 14:47:11 previous meeting: https://www.w3.org/2025/06/12-rdf-star-minutes.html 14:47:11 next meeting: https://www.w3.org/2025/06/19-rdf-star-minutes.html 14:47:27 I have made the request to generate https://www.w3.org/2025/06/13-rdf-star-minutes.html TallTed 14:47:35 ack james 14:47:38 james: I agree with pfps criterion in general. 14:48:14 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 14:48:30 james: So it is going to be different 14:48:50 ack gtw 14:49:24 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 14:49:43 s|s/pfps OPTIONAL/AndyS: OPTIONAL/|| 14:49:43 s/pfps: OPTIONAL already /AndyS: OPTIONAL already / 14:49:46 gtw: In FILTER you take the row you filter, do various replacement in the expression and see if it returns true or not 14:49:52 I have made the request to generate https://www.w3.org/2025/06/13-rdf-star-minutes.html TallTed 14:50:31 q+ 14:50:44 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 14:50:48 ack pfps 14:52:12 pfps: I agree we don't want a MINUS solution but a way to inject values into the FILTER 14:52:51 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... 14:53:23 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 14:54:02 AndyS: This is something we need to come back to 14:54:08 AndyS: let's finish the list 14:54:50 olaf: Next criterion: "bottom-up evaluation" I am not even sure it is possible, perhaps thinking more about it it might be possib/le 14:54:59 q+ 14:55:00 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." 14:55:47 AndyS: This is related on the paper on related paper to rewrite correlated subqueries as joins 14:55:47 ack me 14:57:05 olaf: The intuition is that if it allows to run the subquery only one within the filter I am in favor of that 14:57:45 olaf: next one, address the errata raised on SPARQL 1.1 14:57:59 AndyS: We have a responsibility to not address them but at least take them seriously 14:58:29 AndyS: It also relate to the continuity thing. If it's not an errata, it gives the intuition it's not something to change 14:58:41 AndyS: pfps touch it a bit with "minimality" 15:00:02 olaf: next one "rrefer to do all work in the pre-execution syntax to algebra stage" 15:00:51 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 15:01:02 AndyS: We need to discuss the relationship with SQL correlation 15:01:49 pfps: I agree that all these criteria are good 15:01:57 pfps: But it's difficult to have them all 15:02:25 q+ 15:02:27 q+ 15:02:38 q- 15:02:50 ack olaf 15:03:43 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 15:04:18 pfps: Any solution that modifies the algebra can be changed with a solution that does not change it 15:04:43 pfps: The contradiction I see is between continuity and minimality. continuity might require a more complex solution than one can do 15:05:04 pfps: Maybe there is a minimal solution that maintain as much continuity as possible 15:05:28 pfps: I read continuity as "do not change any response that does not return an error in SPARQL 1.1" 15:06:21 s/continuity/maximum continuity/ 15:06:21 q? 15:06:27 pfps: minimality does not allow to produce things that are not syntacticly correct, and fixing that with deep substition violate continuity 15:06:33 q+ 15:06:39 scribe+ 15:06:45 another definition of continuity would be to not change anything for which there is not an errata 15:07:20 tpt: can we tweak continuality to be "normal case" suggested by the spec? 15:07:23 this is, I think, the continuity that Andy is using 15:08:43 pfps: https://github.com/w3c/sparql-query/issues/156#issuecomment-2390802086 goes against this 15:08:44 https://github.com/w3c/sparql-query/issues/156 -> Issue 156 Addressing SPARQL EXISTS errata (by afs) [ErratumRaised] 15:08:47 (point 2) 15:10:08 Tpt: my proposal is to make a first decision to not turn EXISTS into MINUS and keep some lesser version of continuity 15:10:29 pfps: we would just follow that aspect of SPARQL 1.1 that state that EXISTS and MINUS are different 15:11:26 AndyS: Let's stay on having a look at criteria at the moment, criteria are some kind of opinions 15:11:45 andy? does FILTER EXISTS { { FILTER ... } } show the difference between deep and shallow injection? 15:12:01 james: I am very much partial to bottom up evaluation being a preferable caracteristic 15:12:14 james: It will likely provide evaluation efficiency 15:12:39 james: EXISTS with substitution does not perform very well 15:12:49 james: The scoping rules turn to be an open question 15:13:20 james: How much algebra transformation needs to happen before bottom up evaluation is doable, I don't know 15:14:41 james: I am uncertain to consider if the current variation are all wrong except one or possible approach variation we can take 15:14:46 I have to step out for a bit 15:15:35 gtw: I don't see anything objectionable in the criteria 15:15:59 gtw: I am by default in favor of keeping EXISTS and MINUS as two different approach to negation 15:16:24 gtw: ... with a slight preference to minor changes that stay close with the 1.1 motivations 15:16:57 I'm back 15:17:17 q+ 15:17:52 TallTed: Is your SQL implementation using correlated subqueries 15:18:22 AndyS: The subquery one is an issue to have a look 15:18:53 pfps: Do we have any other proposed solution? 15:19:02 pfps: We have one that is essentially MINUX 15:19:10 s/MINUX/MINUS/ 15:19:58 pfps: SQL has this notion of correlated variable 15:21:17 pfps: I am going to figure out examples like FILTERs inside FILTERs 15:21:44 pfps: Without filters is there any visible difference between different approaches? 15:22:33 AndyS: I have 3 examples, one of these is "SELECT *" 15:23:17 AndyS: we got stuff with UNION and OPTIONAL 15:24:28 s/TallTed: Is your/AndyS: TallTed, Is Virtuoso's/ 15:26:30 q? 15:27:14 ack tpt 15:27:38 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) 15:28:40 zakim, end meeting 15:28:40 As of this point the attendees have been james, AndyS, Tpt, olaf, gtw, gkellogg, TallTed 15:28:42 RRSAgent, please draft minutes 15:28:44 I have made the request to generate https://www.w3.org/2025/06/13-rdf-star-minutes.html Zakim 15:28:50 I am happy to have been of service, AndyS; please remember to excuse RRSAgent. Goodbye 15:28:50 Zakim has left #rdf-star 15:29:00 rrsagent, please excuse us 15:29:00 I see no action items 15:42:47 RRSAgent has joined #rdf-star 15:42:47 logging to https://www.w3.org/2025/06/13-rdf-star-irc 15:42:53 rrsagent, draft minutes 15:42:55 I have made the request to generate https://www.w3.org/2025/06/13-rdf-star-minutes.html TallTed 15:43:45 RRSAgent, bye 15:43:53 RRSAgent, make logs public 15:43:55 RRSAgent, bye 15:43:55 I see no action items