15:56:41 RRSAgent has joined #rdf-star 15:56:46 logging to https://www.w3.org/2026/09/03-rdf-star-irc 15:56:46 RRSAgent, make logs Public 15:56:47 please title this meeting ("meeting: ..."), Andy 15:56:58 meeting: RDF and SPARQL Working Group 15:57:10 previous meeting: https://www.w3.org/2026/08/27-rdf-star-minutes.html 15:57:11 next meeting: https://www.w3.org/2026/09/10-rdf-star-minutes.html 15:57:11 rrsagent, make logs public 15:57:12 agenda: https://www.w3.org/events/meetings/11e4d020-9c58-4fff-83c5-37c9e2502295/20260903T120000/#agenda 15:57:12 clear agenda 15:57:12 agenda+ Progress in Resolving Undefined Errors -> 1 https://github.com/w3c/rdf-n-quads/pull/108#issuecomment-5358467125 15:57:12 agenda+ Review of open PRs, available at -> 2 https://github.com/orgs/w3c/projects/20/views/4 15:57:12 agenda+ Any Other Business (AOB), time permitting 15:57:22 rrsagent, please draft minutes 15:57:23 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html Andy 15:57:29 agenda? 15:58:05 Dominik_T has joined #rdf-star 15:58:07 rubensworks has joined #rdf-star 15:59:01 tl has joined #rdf-star 15:59:18 present+ 15:59:22 present+ 15:59:27 present+ 16:00:33 niklasl has joined #rdf-star 16:00:42 present+ 16:00:45 chair+ 16:00:47 present+ 16:01:25 present+ 16:01:31 present+ 16:01:35 present+ 16:01:44 olaf has joined #rdf-star 16:01:44 present+ 16:01:47 scribe: Tpt 16:01:48 doerthe has joined #rdf-star 16:01:54 present+ 16:02:41 present+ 16:02:49 regrets+ AZ 16:02:57 RRSAgent, draft minutes 16:02:59 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html ktk 16:03:12 Souri has joined #rdf-star 16:03:13 present+ 16:03:15 present+ 16:03:19 Zakim, open item 1 16:03:19 agendum 1 -- Progress in Resolving Undefined Errors -> 1 https://github.com/w3c/rdf-n-quads/pull/108#issuecomment-5358467125 -- taken up [from agendabot] 16:03:38 lisp has joined #rdf-star 16:03:49 present+ 16:04:24 ktk: We have a PR from james on n-quads https://github.com/w3c/rdf-n-quads/pull/108 16:04:25 https://github.com/w3c/rdf-n-quads/pull/108 -> PR 108 Undefined errors (by lisp) 16:04:34 ktk: Should be now migrated to NTriples 16:04:44 https://github.com/w3c/rdf-n-triples/pull/113 16:04:47 https://github.com/w3c/rdf-n-triples/pull/113 -> PR 113 revise consequence of non-conformant documents (by lisp) 16:05:07 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html TallTed 16:06:01 krk: This replaces https://github.com/w3c/rdf-n-triples/pull/107 16:06:02 https://github.com/w3c/rdf-n-triples/pull/107 -> MERGED PR 107 implement TAG recommendation about error handling (by pchampin) [spec:substantive] 16:06:17 fsasaki has joined #rdf-star 16:06:25 regrets+ 16:06:26 ktk: pchampin asked to do a resolution to see if we agree on the PR 16:06:41 q+ 16:06:47 present+ 16:07:22 ack lisp 16:07:32 ora: What we have in the document is the minimal commitment on error 16:07:52 lisp: If there are other documents if they define protocol, then how to handle errors can be defined in these documents 16:08:13 lisp: So the resolution can be that such error management can belong to e.g. SPARQL protocol 16:09:28 q+ 16:10:10 ack pchampin 16:10:31 q+ 16:10:49 ack lisp 16:11:00 pchampin: This PR deems that even signaling is out of scope. A better representation of the PR is "we consider any error signaling or handling as out of scope" 16:11:04 lisp: We agree 16:12:11 q+ 16:12:13 q? 16:12:21 ack lisp 16:12:51 q+ to say maybe but I need to see the words on screen to maybe get to yes/no 16:13:00 ack TallTed 16:13:00 TallTed, you wanted to say maybe but I need to see the words on screen to maybe get to yes/no 16:13:28 q+ 16:13:31 How about: Any error signaling or handling is out of scope for any concrete RDF syntax specification; this will be tackled in a protocol specification 16:13:42 q- 16:14:05 q+ 16:14:09 ack Andy 16:14:38 s/krk:/ktk:/ 16:15:39 Andy: I am not sure what the intent is on "signaling or handling". I agree we should not say anything about the "mechanism". 16:15:43 q+ 16:15:51 ora: can we say "any error handling is out of scope" 16:16:47 ora: the purpuse of a syntax spec is to specify what is the correct language. So, maybe saying "error handling is out of scope" it says we are not commiting to any mechanism 16:16:59 q+ 16:17:06 ack pchampin 16:18:36 ack Tpt 16:18:37 scribe+ 16:18:49 Maybe: "Signaling or handling of syntax errors is out of scope for this or any other specification of a concrete RDF syntax; this will be tackled in {a protocol specification}." Better to say "in the xxx protocol specification." if we can figure it out. 16:19:40 pchampin: this PR is reducing the requirements that is in the spec. The PR is moving from "error should be handled" to "undefined behavior on error" 16:20:01 ora: what about to say "this is a spec for correct language, we do not commit on how expose or handling it" 16:20:59 ora: "the purpuse of a syntax spec is to defined what correct language is". then we say "the specification is not to specify how we signal or handle error" then we say "error handling is left to protocol specifications" 16:21:12 scribe- 16:21:29 I will have tweaks. moment. 16:21:45 ktk: Do we need to be explicit on what language we add to the specification? 16:21:46 s/is to defined/is to define/ 16:21:52 ktk: the text now is very minimal 16:22:06 q+ to quibble with "left to protocol specifications" 16:22:11 q? 16:22:14 ack gtw 16:22:14 gtw, you wanted to quibble with "left to protocol specifications" 16:22:14 How about: ack gtw 16:22:28 s/How about: ack gtw// 16:22:52 "The purpose of a syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error handling is addressed by other specifications, mainly protocol specifications." 16:22:54 gtw: Not all users use a well defined protocol. 16:22:55 q+ 16:23:08 ack lisp 16:23:33 lisp: I would put reporting in the protocol spec, not handling 16:23:52 q+ to nitpick about handling 16:23:58 ack Tpt 16:23:58 Tpt, you wanted to nitpick about handling 16:24:30 "The purpose of a syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error signaling and handing are addressed by other specifications, including but not limited to protocol specifications." 16:25:36 Tpt: handling is a bit in protocol specs, for example stating that on a syntax error no new triple is inserted when POSTing a Turtle document to a graph store endpoint 16:26:33 PROPOSAL: The purpose of a concrete syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error signaling and handing are addressed by other specifications, including but not limited to protocol specifications. All syntax specifications are to be amended to reflect this. 16:26:37 +1 16:26:44 +1 16:26:45 +1 16:26:46 +1 16:26:47 +1 16:26:48 +1 16:26:50 +1 16:26:52 +1 16:26:55 +1 16:26:59 0+ 16:27:00 -0.5 16:27:04 +1 16:27:23 +0 16:27:27 +0.5 16:27:28 +1 16:27:42 RESOLVED: The purpose of a concrete syntax specification is to define correct language. Syntax specifications are not meant to specify how to signal or handle errors. Error signaling and handing are addressed by other specifications, including but not limited to protocol specifications. All syntax specifications are to be amended to reflect this. 16:27:50 rrsagent, draft minutes 16:27:51 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html Dominik_T 16:28:10 q+ 16:28:46 ack pchampin 16:29:54 q+ 16:30:16 ack TallTed 16:30:18 pchampin: my fear is that we might hear that we don't push for interoperability here 16:30:32 TallTed: I don't think our charter is to provide a full stack of spec 16:30:38 +1 16:30:47 q+ 16:30:51 ack ktk 16:31:28 ktk: I see your point pchampin. My takeaway is the TAG is a very narrow use case. We have as a group agreed that there are many other scenarios. 16:32:02 Zakim, next item 16:32:02 agendum 2 -- Review of open PRs, available at -> 2 https://github.com/orgs/w3c/projects/20/views/4 -- taken up [from agendabot] 16:32:57 q+ 16:33:20 ack lisp 16:35:24 #324 is to be withdrawn as it has been superceded 16:35:25 Issue 324 not found 16:35:45 yes 16:35:51 ora: can we merge https://github.com/w3c/rdf-semantics/pull/200 16:35:52 https://github.com/w3c/rdf-semantics/pull/200 -> PR 200 Fix link to "substitution mapping" (by tidoust) 16:37:16 q+ 16:37:52 s/#324 is to be/rdf-tests\/pull\/324 is to be/ 16:38:02 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html TallTed 16:39:01 ktk: for the error PR, we merge in NTriples first then replicate to the other specs 16:39:11 q+ 16:39:27 ack lisp 16:39:27 IMO https://github.com/w3c/rdf-concepts/pull/282 is ready to merge 16:39:28 https://github.com/w3c/rdf-concepts/pull/282 -> PR 282 Reference RFC 9839 in Security Considerations (by domel) 16:39:30 ack olaf 16:39:37 RRSAgent's parsing keeps changing. I'll leave fixing the above to @pchampin 16:39:54 olaf: https://github.com/w3c/sparql-query/pull/417 is new and still need to be reviewed 16:39:54 https://github.com/w3c/sparql-query/pull/417 -> PR 417 Removes blank nodes in the algebraic syntax (by hartig) 16:40:25 olaf: This PR changes the definition of the SPARQL abstract syntax so you don't have blank nodes in the abstract syntax 16:40:48 olaf: This is an outcome of discussions we had two weeks ago, and we agreed it's not needed there 16:41:18 olaf: note this does not prevent blank nodes in the user syntax, their are replaced by fresh variables when the user syntax is parsed into the abstract syntax 16:41:48 olaf: this allows to simplify some things in the semantic, and also simplify property path definitions related to triple term 16:42:22 olaf: I think https://github.com/w3c/sparql-query/pull/400 is in good shape but I would like to see the preview of the current state 16:42:23 https://github.com/w3c/sparql-query/pull/400 -> PR 400 Add SPARQL syntax sections on triple terms, reifiers, and annotations (by rubensworks) 16:44:16 https://lists.w3.org/Archives/Public/spec-prod/2026JulSep/0005.html 16:47:14 https://github.com/w3c/rdf-turtle/pull/157 16:47:15 https://github.com/w3c/rdf-turtle/pull/157 -> PR 157 Move the reifiedTriple syntactic sugar explanation into the note (by domel) 16:47:18 https://github.com/w3c/rdf-turtle/pull/157 16:50:21 https://github.com/w3c/rdf-new/pull/18 16:50:21 https://github.com/w3c/rdf-new/pull/18 -> PR 18 what properties can or should link to triple terms? (by rdfguy) 16:50:41 Zakim, next item 16:50:41 agendum 3 -- Any Other Business (AOB), time permitting -- taken up [from agendabot] 16:50:43 rrsagent, draft minutes 16:50:44 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html Dominik_T 16:52:01 olaf: We need to check that the shared ISWC/TPAC RDF WG time slot is at the same time on both scheduled 16:52:58 s/olaf: We/ora: We/ 16:53:47 26 October 2026, 13:45–16:45 UTC 16:56:29 https://www.w3.org/events/meetings/ed125ed5-2d0a-4ca4-aab6-bfba882ec7fd/ 16:57:11 The overlapping period is therefore 15:45-18:00 CEST, i.e. 2 hours and 15 minutes. 16:57:55 rrsagent, draft minutes 16:57:56 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html Dominik_T 16:59:51 olaf has left #rdf-star 17:00:45 Italy -- Mon 14:45 - Mon 17:45 17:00:51 s/purpuse/purpose/ 17:00:51 s/commiting/committing/ 17:00:51 s/handing/handling/ 17:00:51 s/superceded/superseded/ 17:00:51 s/still need to be reviewed/still needs to be reviewed/ 17:00:51 s/their are replaced/they are replaced/ 17:00:53 s/in the semantic/in the semantics/ 17:00:55 s/on both scheduled/on both schedules/ 17:00:58 RRSAgent, draft minutes 17:00:59 I have made the request to generate https://www.w3.org/2026/09/03-rdf-star-minutes.html ktk