16:01:56 RRSAgent has joined #rdf-star 16:02:00 logging to https://www.w3.org/2025/04/24-rdf-star-irc 16:02:04 meeting: RDF-star WG biweekly focused meeting 16:02:08 present+ 16:02:17 I have made the request to generate https://www.w3.org/2025/04/24-rdf-star-minutes.html TallTed 16:02:29 fsasaki has joined #rdf-star 16:02:30 olaf has joined #rdf-star 16:02:36 present+ 16:02:51 present+ 16:02:51 present+ 16:02:53 scribe+ 16:03:04 present+ 16:03:15 AZ has joined #rdf-star 16:03:19 previous meeting: https://www.w3.org/2025/04/17-rdf-star-minutes.html 16:03:19 next meeting: https://www.w3.org/2025/05/01-rdf-star-minutes.html 16:03:24 present+ 16:03:25 present+ 16:03:26 q+ to ask for a quick slot to update the WG about the SPARQ/EXISTS TF. 16:03:29 chair+ 16:03:34 present+ 16:03:35 present+ 16:03:38 I have made the request to generate https://www.w3.org/2025/04/24-rdf-star-minutes.html TallTed 16:03:44 present+ 16:04:14 agenda: https://www.w3.org/events/meetings/0046d666-d3e8-4032-89e4-8b9a3e6ff40f/20250424T120000/ 16:04:15 clear agenda 16:04:15 agenda+ map the annotation syntax to rdfs:states -> 1 https://github.com/w3c/rdf-star-wg/issues/128 16:04:15 agenda+ naming RDF 1.2 without triple terms -> 2 https://github.com/w3c/rdf-star-wg/issues/135 16:04:15 agenda+ Define RDF 1.2 Basic profile -> 3 https://github.com/w3c/rdf-concepts/issues/70 16:04:17 agenda+ what properties can or should link to triple terms? -> 4 https://github.com/w3c/rdf-star-wg/issues/127 16:04:25 pchampin: news since we last talked. new charter has been approved on last steps by w3c management. 16:04:39 ... changes were sufficient to address concerns. need to draft announcement. rechartered for 2 yeas. 16:04:48 TallTed has changed the topic to: RDF-star weekly meeting -- 2025-04-24 agenda: https://www.w3.org/events/meetings/0046d666-d3e8-4032-89e4-8b9a3e6ff40f/20250424T120000/ 16:05:04 ... as discussed, implemented change of name. new name will be "RDF and SPARQL WG" 16:05:13 ... URLs and mailing list will remain the same. 16:05:47 ora: chairs decided not interested in taking on change of URLs and mailing list. 16:05:58 gkellogg has joined #rdf-star 16:06:00 I have made the request to generate https://www.w3.org/2025/04/24-rdf-star-minutes.html TallTed 16:06:07 ... those can happen after we go to REC. 16:06:07 Zakim, next item 16:06:07 agendum 1 -- map the annotation syntax to rdfs:states -> 1 https://github.com/w3c/rdf-star-wg/issues/128 -- taken up [from agendabot] 16:06:34 s/for 2 yeas/for 2 years/ 16:06:40 tl: mostly negativie discussion, not in support of proposal. 16:06:47 present+ 16:07:17 q- 16:07:18 ... ambivalence in my proposal which I hadn't recognized. now I recognize why pfps said it was propositional attitude. 16:08:06 ... If you want it clearly expressed that reification is stated in graph, why not add a type "this is stated reification"? I thought that was unreasonable. You can't expect that to be added all the time. 16:08:29 something missing is *never* expressing anything in RDF; Open World Assumption 16:08:53 ... But now I thought maybe we can do it the other way around. If I reify the propisition, just add a "not endorsed" class. Expect that to be much more seldom. 16:08:55 ... Could be a reasonable burden. 16:09:13 ... If you want people to know this annotation doesn't endorse, then you've got a way to express it. 16:09:30 ... Maybe that's good enough. I'm now thinking about that. Much less burden on everybody else. 16:09:53 ... It would have other traps. Still open questions. Would this be required for mapping from reification shorthand? 16:10:18 ... When we use chevron in subject position, should that be expected to map to a new type "unendorsed propisition"? 16:10:39 ora: You're still thinking about it? Should we not be discussing this today? 16:10:48 q+ 16:10:57 ack james 16:10:59 tl: I don't want to waste time, but comments now ... happy to listen. 16:11:15 james: I have noto been able to comprehend all the comments in last 24h. Want opportunity to do that before reaching any decisions. 16:11:34 A+ 16:11:36 ora: any other strong feelings? 16:11:39 q+ 16:11:48 ack enrico 16:12:14 enrico: My problem is that these decisions are moving targets. Is this about shortcut? I don't know. 16:12:49 q+ 16:12:58 ora: Not is not the time to discuss this. 16:13:00 ack pchampin 16:13:15 william-vw has joined #rdf-star 16:13:26 pchampin: I agree with enrico. It has become a moving target. Would it make sense to close this issue and open a new one with a specific proposal? 16:13:35 ... for the sake of clarity. 16:13:44 q+ 16:13:55 ack tl 16:13:56 ... I would rather close the perma-issue. Title and lots of the discussion are moot. 16:14:17 tl: Not really. Initial comment still stood until late tonight. 16:14:21 ... not that much moving. 16:14:32 ... One ore two proposals to react to criticism. The reactions are moving. 16:14:48 ... Others did endorse rdf:states in the past. Just not mapping from the annotation syntax. 16:15:12 ... Moving target is not entirely fair. I adjust to responses. 16:15:27 ... A very strong thing if the triples are in the graph or not. If you're annotating things in the graph or not. 16:15:43 ... That's so important. Can't imagine we don't have a way to say that. 16:15:49 ... That hasn't changed at all. 16:16:03 ... I can open a new issue, write a new summary. 16:16:07 q+ 16:16:10 ... I fear we will have the same discussion again in the new issue. 16:16:31 ora: I like what pchampin suggests. Why don't we do that. Open new issue. Write a new succint summary. 16:16:53 ... Important for everybody to get a clear understanding of the proposal and why. 16:17:20 doerthe has joined #rdf-star 16:17:23 enrico: I insist that the new proposal should be clearly distinguished from what is proposed in the text. 16:17:24 present+ 16:17:40 ... Why do you want that? What is not clear is what is the change that is proposed. 16:17:53 ... We need to discuss the proposal, and you need to convince why the proposal makes sense or not. 16:18:26 ora: Almost never a good idea to bring a half-baked proposal. Much better to have a very clearly thought-out proposal that answers all the questions. 16:18:37 Zakim, next item 16:18:37 I see a speaker queue remaining and respectfully decline to close this agendum, TallTed 16:18:38 s/rdf:states/rdfs:states/ 16:18:42 q? 16:18:46 ack enrico 16:18:49 ack enrico 16:18:52 Zakim, next item 16:18:52 agendum 2 -- naming RDF 1.2 without triple terms -> 2 https://github.com/w3c/rdf-star-wg/issues/135 -- taken up [from agendabot] 16:19:11 q+ 16:19:28 ora: the two agenda items (this and next) are related. 16:19:40 ack AZ 16:19:54 pfps has joined #rdf-star 16:19:54 AZ: The issue is about naming 1.2 graphs that do not contain triple terms. 16:19:57 i|ora: the two|https://github.com/w3c/rdf-concepts/issues/70 16:20:04 present+ 16:20:06 ... something that would be similar to RDF 1.1 graphs. 16:20:16 https://github.com/w3c/rdf-concepts/issues/70 16:20:16 https://github.com/w3c/rdf-concepts/issues/70 -> Issue 70 Define RDF 1.2 Basic profile (by gkellogg) [needs discussion] [spec:enhancement] 16:20:18 I'm here, but I only recorded the issue 16:20:29 ... issue was opened almost a year before we had resolution about this. Including the naming of RDF graphs without triple terms. 16:20:46 ... the choice was to name this part of RDF "1.2 Basic". Therefore there isn't an issue. We already decided. 16:20:55 ora: This is my recollection. 16:21:10 ... What do people think? Have opinions changed? 16:21:16 q? 16:21:17 q+ 16:21:17 q+ 16:21:31 ack tl 16:21:33 tl: What do you say about the conversion? 16:21:35 ack AndyS 16:21:40 [didn't catch tl's comment] 16:21:52 AndyS: Does RDF 1.2 Basic graph allow text direction? 16:22:16 AZ: I think proposal was that yes, it does, because RDF 1.2 Basic was only disregarding triple terms. 16:22:22 ... idea is to include everything but triple terms. 16:22:44 ora: why would we come up with a name? Wouldn't that be RDF 1.1? 16:22:49 s/[didn't catch tl's comment]/one needs a verb: "classify" works, "basicify" doesn't 16:22:55 pchampin: I confirm that's what the resolution said. 16:23:19 ora: we have decided. don't need to decide again unless objection. 16:23:31 ... next item is to define what it is. Seems we also have a good understanding of what that is. 16:23:32 q+ 16:23:39 ora: why do we need a verb? 16:23:51 tl: can be "convet to basic". 16:23:51 ack AndyS 16:23:59 I think the verb is "classicise"though? (Successor to "unstar"...) 16:24:07 AndyS: does this imply that the property rdf:reifies is not used in such a graph? 16:24:20 ... does it exclude the vocabulary? or just no triple terms? 16:24:29 ... I would prefer rubish in, rubish out. 16:24:41 ora: If you have A reifies B, what would that mean? 16:24:41 q+ 16:24:41 q+ 16:24:46 AndyS: I don't think that has a sensible meaning. 16:24:51 ack enrico 16:24:57 enrico: It has a very precise meaning. 16:25:19 :a rdf:reifies :b . :b a rdfs:Proposition . 16:25:25 ... A refies B, even if B is not a triple term, is a proposition. 16:25:30 q- 16:25:38 ... we could have that. 16:25:50 ... rdfs:reifies range implies a proposition. 16:25:56 ... it's still meaningful. 16:26:08 ora: 1.2 Basic disallows triple terms and nothing else. 16:26:28 ... already discussion next agendum 16:26:28 that sounds reasonable to me 16:26:30 q+ 16:26:37 q+ 16:26:40 ack pchampin 16:26:52 I have made the request to generate https://www.w3.org/2025/04/24-rdf-star-minutes.html TallTed 16:27:01 pchampin: we have a resolution that dates a year ago. this resolution was never implemented. makes sense to ask ourselves why. 16:27:24 ... one way is to create an action to implement the resolution. 16:27:28 s/that sounds reasonable to me/only disallowing triple terms sounds reasonable to me as well 16:27:40 ... as for AndyS's questions, maybe we can check with strawpoll to restrict definition to just no triple terms. 16:27:46 q+ 16:27:49 ... maybe that's not needed as it was already resolved. 16:28:04 STRAWPOLL: RDF 1.2 Basic is RDF 1.2 without Triple Terms 16:28:20 +1 16:28:21 +1 16:28:23 +1 16:28:25 +1 16:28:27 +1 16:28:28 +1 16:28:29 +1 16:28:30 +1 16:28:30 +1 16:28:32 +0.75 16:28:32 +1 16:28:38 +1 16:28:38 +1 16:28:41 +1 16:28:42 +1 with VERSION "1.2-basic" 16:28:56 niklasl: probably +1, but regarding motivation. 16:29:03 ±0 I haven't considered this framing in quite some time 16:29:10 ... versioning of syntaxes. it's not entirely orthogonal to this. 16:29:36 ... if we have someone who is asking for data from dataset which contains RDF 1.2 (triple terms) and literals with direction. 16:29:52 ... and they say "I only understand 1.1", you might want to provide consumer with as much data as possible anyway 16:30:07 ... so you would turn it into RDF 1.2 Basic and serialize. But that doesn't work for direction. 16:30:23 ... not entirely certain use-case for having this basic profile is only about the triple terms. 16:30:27 ... might also be about direction. 16:30:49 ora: If we were to exclude direction also, why wouldn't the server respond that it's RDF 1.1? 16:30:59 niklasl: because rdf:reifies is not in 1.1. 16:31:09 ora: and RDF is a closed namespace. 16:31:11 q+ 16:31:23 niklasl: we've added things into the namespace since 1.1, right? 16:31:27 AndyS: rdf:JSON 16:31:50 ack james 16:31:57 q- 16:32:02 q+ 16:32:18 james: the implications of enrico's description, what would be the meaning of having a reifies statement that has as object the subject of a 1.1 reification? 16:32:30 ... does that have any significance? 16:32:47 q+ 16:33:04 enrico: we have deprecated the old reification. you can write it, but from newer perspective, this is not advisable or meaningful. 16:33:26 james: even in Basic? 16:33:37 enrico: use case for Basic is you can keep older implementations. 16:33:58 I think the possible meaning is related to the informal "classicised" form. 16:34:01 ... otherwise there are so many small details that have changed from 1.1, what do we leave from 1.2 for basic? 16:34:19 ... this was born because people not willing to implement triple terms. 16:34:43 james: if you only exclude triple terms type, and have 1.2 deprecated form, would it be acceptable as having meaning of naming the reification (again)? 16:34:44 q+ 16:34:50 ack pchampin 16:34:51 ... or would that itself be deprecated? 16:35:10 pchampin: numer of subtle differences between 1.1 and 1.2. 16:35:13 s/numer/number/ 16:35:21 [ a rdf:Statement ] rdf:reifies [ a rdfs:Propositon ] . 16:35:28 ... my understanding for need for Basic profile is that triple terms add significant complexity to model. flat to recursive. 16:35:40 ... some implementations might not want to take on that burden. 16:35:56 s/rdfs:Propositon/rdfs:Proposition/ 16:36:16 ... to james' point, doing what you suggest is legal syntactically, not semantically inconsistent. 16:36:28 ... does not have same meanign as the similar use of triple terms with same components. 16:36:33 s/meanign/meaning/ 16:36:34 ack gkellogg 16:36:59 gkellogg: I'm mostly inline with what pchampin just said. Compatibility with 1.1 is defined by 1.1 specs. Not our job to provide a way to seamlessly transition between 1.2 and 1.1. 16:37:23 ... the purpose of a basic profile is not to deal with minor changes such as base direction of text. the structural differences that triple terms bring. 16:37:46 ... we need to focus on motivation for that. stop thinking overly about needs of people that have implemented 1.1 to do the least they need to to claim 1.2 compatibility. 16:37:47 ack enrico 16:37:52 q- 16:38:00 ack niklasl 16:38:32 niklasl: I wrote out clarification. Meaning would not be the same as classic reification. RDF 1.1 reification is a statement. That can be seen as reifying a proposition. 16:38:48 ... related to that procedure... formerly known as unstarring. 16:39:15 ... those terms are tricky to use right. you should upgrade to 1.2 and use triple terms. otherwise you'll use them wrong eventually. 16:39:16 q+ 16:39:23 ack AndyS 16:39:43 AndyS: we've always talked about the issues around 1.1, will a system be able to ingest 1.1. 16:39:52 ... the step of fetching and using may not be the same. 16:40:05 ... I think we can do something like have explicit version label for RDF 1.1. 16:40:15 ... can be meaningful. can add to code request. know what you're getting back. 16:40:36 ... if you're going to republish data, you might be able to cope with 1.2. but maybe downstream clients won't be able to handle 1.2. 16:40:43 +1 to AndyS 16:40:44 ... need a strict 1.1 ability. 16:41:01 ora: somebody needs to write a proposal on exactly how we want to define this. 16:41:02 accept: text/turtle?version=1.1 could be used, and makes sense to me 16:41:11 q? 16:41:12 ... then it can go into Concepts. 16:41:16 "rdf:reifies" does not do much anyway, it's just a property that makes the object an instance rdfs:Proposition 16:41:26 +1 AZ 16:41:31 (at least in the current version of RDF 1.2 semantics) 16:41:44 AndyS: if we can do that as part of defining the labels, I can do that. 16:41:54 ... if it's open-ended, I haven't got the time. 16:42:03 s/an instance rdfs:Proposition/an instance of rdfs:Proposition 16:42:05 ora: it's fairly contained. 16:42:13 +1 to pchampin; +1 to AZ 16:42:35 ora: will await writeup 16:42:36 https://github.com/w3c/rdf-star-wg/issues/135 -> Issue 135 naming RDF 1.2 without triple terms (by pfps) [needs discussion] 16:43:07 Zakim, next item 16:43:07 agendum 3 -- Define RDF 1.2 Basic profile -> 3 https://github.com/w3c/rdf-concepts/issues/70 -- taken up [from agendabot] 16:43:21 ora: already discussed this. 16:43:28 Zakim, close item 3 16:43:28 agendum 3, Define RDF 1.2 Basic profile -> 3 https://github.com/w3c/rdf-concepts/issues/70, closed 16:43:30 I see 1 item remaining on the agenda: 16:43:30 4. what properties can or should link to triple terms? -> 4 https://github.com/w3c/rdf-star-wg/issues/127 [from agendabot] 16:43:36 Zakim, next item 16:43:36 agendum 4 -- what properties can or should link to triple terms? -> 4 https://github.com/w3c/rdf-star-wg/issues/127 -- taken up [from agendabot] 16:44:06 ora: Semantics TF discussed this? 16:44:18 AndyS: I raised the issue. Not sure it's still valid. 16:44:35 ora: there is a conclusion from TF from two weeks ago. 16:44:46 sorry I was disconnected 16:44:47 q+ 16:44:53 ack niklasl 16:45:14 niklasl: I believe we agreed that liberal baseline - we are not forbidding using any property with triple term as object. 16:45:23 q+ 16:45:25 yes, a formal resolution appears to be indicated 16:45:27 https://github.com/w3c/rdf-star-wg/issues/127#issuecomment-2797199065 16:45:28 https://github.com/w3c/rdf-star-wg/issues/127 -> Issue 127 what properties can or should link to triple terms? (by afs) [needs discussion] 16:45:32 ... related was an issue from Souri, nesting triple terms. 16:45:43 ... I think closing this would not block that. 16:45:50 Franconi 16:45:51 left a comment 16:45:51 (w3c/rdf-star-wg#127) 16:45:51 We discussed at the Semantics TF and we reached this conclusion: 16:45:52 Conclusion 1: we discussed about restricting (or suggesting to restrict) the usage of triple terms only as object of rdf:reifies, but we believe that their usage should be unrestricted. 16:45:52 This conclusion will be brought forward for discussion in the WG. 16:45:53 q? 16:46:10 ack pchampin 16:46:26 pchampin: I think the issue raised by niklasl is orthogonal to that one. 16:46:41 ... even if we restrict triple terms to only rdf:reifies, we can still make a triple term where predicate is rdf:refiies. 16:46:50 ... nesting is orthogonal to whether we allow other predicates. 16:46:58 ... I personally agree with conclusion of TF. 16:46:59 https://www.w3.org/TR/rdf12-concepts/#h-note-6 16:47:05 ... How does it impact this note [linked]? 16:47:15 q+ 16:47:32 ... enrico said is fine with semantics already. 16:47:34 ack enrico 16:47:48 enrico: my argument is that triple terms are orthogonal to reification. 16:48:00 ... may not use rdf:reifies. 16:48:10 ... can use rdf:reifies without triple terms. perfectly fine meaning. 16:48:26 I don't think they're orthogonal with the restriction of triple terms to the object position ... 16:48:26 ... I would just never mention the fact that we discourage these combinations. Leave complete freedom. 16:48:41 ... that's what semantics says. Don't want to block future of more creative uses. 16:48:56 ... Any reference to SHOULD or MUST should just disappear. 16:48:58 q+ 16:49:03 ack pchampin 16:49:08 +1 to enrico 16:49:21 pchampin: This NOTE contains normative language which is a mistake. This will be fixed. 16:49:24 The issue (by Souri) I mentioned: https://github.com/w3c/rdf-star-wg/issues/155#issuecomment-2817199248 16:49:25 https://github.com/w3c/rdf-star-wg/issues/155 -> Issue 155 Would compliance require support for arbitrary recursion in a triple-term? (by sdasoracle) 16:49:26 ... as that is specifically tailored towards encouraging reifiers, I believe 16:49:28 ... not suggesting to make this normative. 16:49:44 ... still good to have this guidance. I agrees sky is the limit. 16:49:57 ... rationale to introducing triple terms was to have better way to do reification. 16:50:09 ... I don't think we have clear use-cases or best practices to use them otherwise. 16:50:22 ... I'd be against making this normative, but having a note with proper language is still a good idea. 16:50:30 ora: You are suggesting some other language? 16:50:49 pchampin: I suggest we keep the note but fix the normative language. 16:51:08 q+ 16:51:14 ora: Do we express any kind of guidance? 16:51:15 q+ 16:51:15 q+ 16:51:27 ... If I interpret enrico correctly, maybe there shouldn't be any guidance. 16:51:27 ack niklasl 16:51:45 niklasl: we do by having syntax that encourages rdf:reifies. annotation syntax in turtle. 16:51:45 q+ to suggest "a common pattern is to ..." 16:51:58 ... proposed in RDF/XML, JSON-LD. All cater to using rdf:reifies. 16:52:19 ... I thikn that's aligned with NOTE language. 16:52:26 s/palces/places/ 16:52:42 ack james 16:53:03 james: I prefer recommendations that say only what they need to. This NOTE doesn't add any meaning. Doesn't help the user. 16:53:10 ack tl 16:53:10 ... the rest of the recommendation does that. 16:53:21 tl: Will we have a NOTE explaining the new triple term reification mechanism? 16:53:25 ... An extra document? 16:53:34 ack AndyS 16:53:34 AndyS, you wanted to suggest "a common pattern is to ..." 16:53:35 I don't see why there should be guidance for rdf:reifies while we don't have guidance about rdf:List, rdf:first, rdf:rest, rdf:nil, for instance 16:53:56 AndyS: Trying to come up with different terms to say a pattern could be used. 16:54:09 q+ 16:54:10 I like the notion of pattern 16:54:10 ... doesnt' say "should". Less directive force than "should" even in informal sense. 16:54:16 ack enrico 16:54:32 enrico: I believe this NOTE should just not be there. We spent a lot of time in Concepts to explain how to write reifications. 16:54:40 ... it's explained everywhere. Main point of RDF 1.2. 16:54:47 ... NOTE does not say much more about how to do reification. 16:55:03 ... It does suggest only using triple terms for reification. 16:55:11 ... may hamper some future. 16:55:16 ora: any objections to the NOTE going away? 16:55:21 q+ 16:55:30 ack william-vw 16:56:01 william-vw: That restriction that was voted on... triple terms only in the object position. That was done to encourage the use of reifiers? 16:56:18 q+ 16:56:22 ... for me, this was restricting too much. Clearly points towards the intent of WG to push for reification. 16:56:31 ... two issues are not orthogonal. Not from a practical viewpoint. 16:57:00 ... I do feel there should be guidance on how to use this particular construct. Always with reification. 16:57:05 ack niklasl 16:57:21 niklasl: I do agree with that. I think the primer does something to that effect. We can work more on that. 16:57:39 ... We do not encourage any other way to use triple terms. 16:57:52 ... We don't want to discourage that. One way is to say nothing. 16:58:13 ... Perhaps only information needed is already in there. Wouldn't mind informative language in there. 16:58:34 ora: Maybe we should have some explanation. 16:58:43 william-vw as niklasl and enrico pointed out, this "encouragement" to use rdf:reifies is in many other places, starting with the syntactic sugar and the examples in the primer 16:58:59 niklasl: not sure we can give clear guidance at this point on other uses. 16:59:15 ... relationship with named graphs and reifiers, lists, etc. 16:59:27 pchampin why not make it clear by having a separate NOTE? 16:59:34 * even clearer 16:59:36 ... without clear explanations, there is something for having some informative text on reifiers as the way we know how to use. 16:59:49 instead of spreading it across documents 16:59:55 ora: need some sort of explanatory text. 16:59:59 RDF-star SPARQL TF : https://www.w3.org/2025/04/23-rdf-star-minutes.html 16:59:59 Meeting slot will reuse the SemanticsTF slot (Fridays, 4pm CEST) starting 2nd May. 16:59:59 (i.e. not tomorrow 25/April) 17:00:19 RRSAgent, make minutes 17:00:21 I have made the request to generate https://www.w3.org/2025/04/24-rdf-star-minutes.html pchampin 17:01:05 m2gbot, link issues with transcript 17:01:06 comment created: https://github.com/w3c/rdf-star-wg/issues/128#issuecomment-2828287426 17:01:07 comment created: https://github.com/w3c/rdf-star-wg/issues/135#issuecomment-2828287455 17:01:08 comment created: https://github.com/w3c/rdf-concepts/issues/70#issuecomment-2828287498 17:01:09 comment created: https://github.com/w3c/rdf-concepts/issues/70#issuecomment-2828287531 17:01:10 comment created: https://github.com/w3c/rdf-star-wg/issues/127#issuecomment-2828287560 17:03:02 olaf has left #rdf-star 17:23:27 gkellogg has joined #rdf-star 17:45:40 gkellogg has joined #rdf-star 18:11:14 Zakim, end meeting 18:11:14 As of this point the attendees have been james, TallTed, gtw, AndyS, fsasaki, niklasl, AZ, ora, tl, olaf, pchampin, gkellogg, doerthe, pfps 18:11:17 RRSAgent, please draft minutes 18:11:18 I have made the request to generate https://www.w3.org/2025/04/24-rdf-star-minutes.html Zakim 18:11:24 I am happy to have been of service, TallTed; please remember to excuse RRSAgent. Goodbye 18:11:24 Zakim has left #rdf-star 18:11:25 RRSAgent, bye 18:11:25 I see no action items