16:57:03 RRSAgent has joined #rdf-star 16:57:08 logging to https://www.w3.org/2025/02/13-rdf-star-irc 16:57:08 Zakim has joined #rdf-star 16:57:17 I have made the request to generate https://www.w3.org/2025/02/13-rdf-star-minutes.html TallTed 16:57:30 agenda: https://www.w3.org/events/meetings/3f89f9e9-2ddb-4587-8c60-2dfdc927320a/20250213T120000/ 16:57:32 clear agenda 16:57:32 agenda+ Which parties carry what costs of text/turtle changes, and do those outweigh which benefits for whom? -> 1 https://github.com/w3c/rdf-star-wg/issues/141 16:57:32 agenda+ Triple terms in subject position - issues with RDF/XML? -> 2 https://github.com/w3c/rdf-star-wg/issues/138 16:57:32 agenda+ Un-star operation to support RDF Dataset Canonicalization? -> 3 https://github.com/w3c/rdf-star-wg/issues/114 16:57:33 agenda+ Move reference versions of the RDF and RDFS vocabulary to this repo -> 4 https://github.com/w3c/rdf-schema/pull/33 16:57:50 present+ 16:58:32 present+ 16:58:38 present+ 16:58:45 previous meeting: https://www.w3.org/2025/02/07-rdf-star-minutes.html 16:58:45 next meeting: https://www.w3.org/2025/02/14-rdf-star-minutes.html 16:58:56 tl has joined #rdf-star 16:59:22 I have made the request to generate https://www.w3.org/2025/02/13-rdf-star-minutes.html TallTed 16:59:43 present+ 16:59:55 enrico has joined #rdf-star 16:59:58 fsasaki has joined #rdf-star 16:59:59 present+ 17:00:09 present+ 17:00:10 present+ 17:00:18 meeting: RDF-star WG biweekly focused meeting 17:00:22 ora has joined #rdf-star 17:00:26 olaf has joined #rdf-star 17:00:41 present+ 17:00:41 pfps has joined #rdf-star 17:00:47 present+ 17:00:52 present+ 17:00:57 chair+ 17:01:02 present+ 17:01:02 james has joined #rdf-star 17:01:08 eBremer has joined #rdf-star 17:01:19 present+ 17:01:27 scribe: Tpt 17:01:36 present+ 17:01:56 Dominik_T has joined #rdf-star 17:02:13 present+ 17:02:15 I have made the request to generate https://www.w3.org/2025/02/13-rdf-star-minutes.html TallTed 17:02:27 present+ 17:02:40 AZ has joined #rdf-star 17:02:56 zakim, open item 1 17:02:56 agendum 1 -- Which parties carry what costs of text/turtle changes, and do those outweigh which benefits for whom? -> 1 https://github.com/w3c/rdf-star-wg/issues/141 -- taken up 17:02:59 ... [from agendabot] 17:03:17 present+ 17:03:23 q+ 17:03:45 ora: Something from Ruben Verborgh. Any thoughts? 17:03:50 ack pfps 17:04:40 pfps: This is not limited to Turtle, RDF/XML, NTriples... all of our surface syntax are exactly in the same situation 17:04:57 rubensworks: also the SPARQL results syntaxes 17:05:08 q+ 17:05:16 q+ 17:05:19 ora: We need to things, eventually a solution and before that a response to Ruben 17:05:27 ack rubensworks 17:05:37 rubensworks: Based on some scrawling, several solutions have been proposed 17:05:49 rubensworks: the simplest one, do nothing and carry on with the changes 17:06:21 rubensworks: Second solution, introduce new media type but it comes with some cost, adoption, web browser restrict accept header length 17:06:32 rubensworks: An other is to make use of profiles 17:07:05 rubensworks: An other and it's the one I am personnaly in favor of is to keep the media type but introduce some in syntax version mechanism just like JSON-LD and HTML 17:07:19 q+ 17:07:51 q+ 17:07:53 ack gtw 17:08:04 rubensworks: the motivation is that currently text/turtle means Turtle 1.1 and if we change that, the contract break 17:08:41 TallTed: All line based formats will have a hard time for in format versionning but it sounds a good approach for eg Turtle 17:08:59 s/TallTed:/gtw:/ 17:09:00 ack AndyS 17:09:23 gtw: if not, we open ourselves to get new media type each time a WG update the spec 17:10:05 q+ 17:10:15 AndyS: My personal concern is that to fix a problem we pay occasionally, we split the world in two 17:10:42 AndyS: If there is an inline version thing, then there is a choice, is it mandatory or optional to use RDF 1.2 features? 17:10:53 ack pchampin 17:12:15 q+ 17:12:32 pchampin: I like the idea of optional inline version with the statement "you should add a version if you use RDF 1.2 features such that clients can break gracefully" 17:13:34 ack fsasaki 17:13:38 pchampin: Line formats makes versionning harder but error recovery much easier, you can just restart on the next line 17:14:27 ack james 17:15:28 q+ 17:15:34 ack AndyS 17:15:46 james: With content negotiation, I have expected that the server can answer with whatever it wants 17:16:51 AndyS: A syntax error is not a new class of error a web system would have to deal with anyway 17:17:12 ora: I am not sure a HTML-like recovery system would be a good thing for RDF 17:17:43 ora: If there is something the client does not understand, the client should know it does not understand 17:17:51 well, RDF is monotonic, so a subset of the triples would at least not contradict the whole graph 17:18:11 q+ 17:18:17 ack niklasl 17:18:22 ora: we need a decision on the principles, even if we don't deal with the details of the decision yet 17:18:27 just to add me comment to the minutes: having the HTML / CSS / JavaScript way of "doing nothing" may have some benefits, going the path of loose coupling a bit more than done so far for RDF 17:18:45 I have made the request to generate https://www.w3.org/2025/02/13-rdf-star-minutes.html fsasaki 17:20:22 q+ 17:20:27 q+ 17:20:29 ack james 17:20:31 ora: How this inline mechanism work in Turtle? 17:21:09 ack pchampin 17:21:26 (My notes that I pseudo-read-from): I'm +1 to keep media type. Excellent points by all. I think focus is best spent on considering viability/workability of a version parameter; and also pro/con of in-band (version keyword in "prelude") (break early; mandatory or not)? With considerations on what is deployed out there, and when clients/servers are 17:21:26 likely to upgrade to 1.2 (as in make use of the new features; cf. unstarring). Error recovery is also very interesting (I think CSS is particularly interesting in that respect). 17:21:32 james: My point is not only that the server can return the content-type it wants but it can also provide the adequate signal for the client to understand why it might fail 17:21:48 doerthe has joined #rdf-star 17:21:55 present+ 17:22:54 pchampin: The inline mechanism should be a SHOULD because there are situation where it is hard for publisher to know if they are going to make sure of specific features like triple terms 17:22:57 q+ to ask about general toolkit (e.g Spring) support for "version=" 17:23:23 pchampin: and so to mak sure that in the happy case (no triple term) the old implementation still work 17:23:30 ack AndyS 17:23:30 AndyS, you wanted to ask about general toolkit (e.g Spring) support for "version=" 17:23:44 +1 to an optional (SHOULD) @version parameter, since it allows to break early and with explanation 17:24:15 AndyS: I don't know the state of the world is out there, if you send a `version=` parameter on a media type, would framework like Spring fail or handle it properly? 17:24:26 q+ version parameter optional? 17:25:31 q? 17:25:33 q+ 17:25:37 pchampin: the version parameter of requests should be optional 17:25:44 ack pchampin 17:26:48 pchampin: I will update my FOAF profile to serve the response with `version=1` and send a message to the semweb mailing list to see if implementations choque on it 17:27:31 ora: Would it make sense to enumerate what the difference approaches mean for the different syntaxes? 17:27:39 s/choque/choke/ 17:28:06 q+ 17:28:15 ack rubensworks 17:28:21 doerthe has joined #rdf-star 17:28:28 present+ 17:28:40 Yes; one or both of 1) version keyword and 29 version parameter on existing media types? 17:28:58 s/29/2)/ 17:29:01 rubensworks: I am not sure if it make sense to enumerate all approaches even if it seems that the inline version in addition to the version= media type parameter seems to get traction 17:30:18 ora: I am wondering should we somehow clearly spell what the failure modes are and possible courses of actions 17:31:04 q? 17:31:07 zakim, open next item 17:31:07 agendum 2 -- Triple terms in subject position - issues with RDF/XML? -> 2 https://github.com/w3c/rdf-star-wg/issues/138 -- taken up [from agendabot] 17:31:17 q+ 17:32:00 ack tl 17:32:49 tl: We had a discussion at the semantic task force, I find it dangerous to forbid triple term in subject positions 17:33:17 tl: RDF is very liberal, the parallel to literals is very flawed 17:34:03 tl: I am afraid we are narrowing too much on provenance annotations 17:34:08 q+ 17:35:28 https://github.com/w3c/rdf-concepts/issues/138#issuecomment-2653293297 17:35:29 https://github.com/w3c/rdf-concepts/issues/138 -> Issue 138 Triple Terms in Subject Position (by rat10) [ms:CR] [spec:substantive] 17:35:49 tl: to discuss the statement itself triples terms in subject position should be allowed 17:36:18 it is "theoretically possible" to do lots of things, so no warning about it is needed 17:37:11 tl: we should not only focus on occurences and miss types completely 17:37:26 ack niklasl 17:39:03 niklasl: for me it's clear for quoted triples are abstract things, I just disagree to a lot of conclusion, see the discussions 17:39:45 q+ 17:39:55 ack james 17:40:52 Add as little as is needed. (See also https://en.wikipedia.org/wiki/Rule_of_least_power .) 17:41:28 james: I don't believe the comitee understand things well enough to enforce restrictions. I would not exclude symmetry. 17:42:23 Symmetry is already excluded (literals). See also "symmetric RDF" in https://www.w3.org/TR/rdf12-concepts/#section-generalized-rdf 17:43:09 STRAWPOLL: Allow triple terms in subject position 17:43:13 ora: I would like to take a strawpool on how people feel about this 17:43:14 -1 17:43:16 +1 17:43:17 +1 17:43:19 +0 17:43:21 -0.7 17:43:23 +1 17:43:27 -1 17:43:29 +0 17:43:30 -0.5 17:43:34 +0 17:43:36 +1 17:43:37 -1 17:43:37 -0.5 17:43:40 -0.7 17:43:42 +0 17:43:45 -0.1 17:44:07 0 17:44:09 -epsilon There is no technical harm, but I forsee the seminal example rising its ugly head again. 17:44:32 ora: There is no concensus, how do we resolve this? 17:44:32 There was already a strawpoll about this on January 30th. 17:44:39 What is possible to undo if the wrong choice is made? 17:44:55 q+ 17:45:07 ora: Symmetry may not be the final convincing argument, RDF is not symmetric with literals 17:45:12 ack pchampin 17:46:29 AZ -- It's natural for straw poll results for the same question to change over time, even short term. They're entirely non-binding, and just to get a sense of people's feeling at the moment they're run. 17:46:32 q+ 17:46:41 pchampin: My personnal preference is to allow them in subject position just like literal. I voted -0.5 because I heard some implementers are scared about it and we made the decision to disencourage the usual of triple terms outside of the object of rdf:reifies 17:47:09 Also +1 to pfps; that (seminal examples cropping up all over; users asking about what to do) is more concretely my concern. 17:47:20 q+ to ask if this could be handled with some kind of conformance definition 17:47:22 pchampin: If we allow triple terms in subject position, we should reconsider the "SHOULD be used as object of rdf:reifies" in concepts 17:47:24 ack james 17:47:27 but discouraging is not the same as not allowing 17:47:28 q+ 17:48:04 james: What is that so hard to have triple terms in subject positions? 17:48:16 I think the "discouraging" was already the compromise 17:48:27 ack ora 17:48:27 ora, you wanted to ask if this could be handled with some kind of conformance definition 17:48:46 If literals had been allowed as subjects, I am far from convinced users would have picked up that data like `"Eureka" :saidBy "Archimedes"; :inLanguage "el" .` is a Bad IdeaTM. 17:49:53 q+ 17:49:59 ack tl 17:50:17 pchampin: an option might be to allow triple terms in subject position only in generalized/symmetric RDF 17:50:45 tl, you're looking for owl:sameAs 17:51:24 OK, niklasl, but in your example it does harm because that is something many people will do with EXACTLY that string 17:51:44 ack fsasaki 17:52:16 doerthe, I know, I do understand the risk-level difference (who "owns" the combo of all three constituents). 17:52:57 @niklasl that's a possible workaround, but I'd like this issue to be addressed in RDF proper 17:53:59 pchampin: My implementation internal data structures support generalized RDF. The parsers are complient and there is an additional "generalized TriG" syntax and for serializing there is a flag to prevent it to serialize things outside of standard RDF 17:54:33 q+ 17:54:35 When in doubt, only add what is *needed*. 17:54:36 ora: I would like to understand what the road for concensus would be 17:54:41 ack fsasaki 17:55:10 @niklasl is prohibiting needed? 17:55:19 fsasaki: what about classifying the vote with "can live with" and "cannot live with" 17:55:34 +1 to have 2 polls: "I can live with TT in subject position", "I can live with TT forbidden in subject position" 17:55:57 if one of them has no objection, then we have at least a weak consensus 17:56:18 @tl, define prohibit. We prohibit triples to be three-tuples as opposed to n-tuples? 17:56:37 if both get objections, we need to record dissent and move forward 17:56:55 ora: no extra point? 17:57:13 niklasl half-full vs half-empty gasses etc 17:57:20 RRSAgent, make minutes 17:57:22 I have made the request to generate https://www.w3.org/2025/02/13-rdf-star-minutes.html pchampin 17:58:26 olaf has left #rdf-star 19:40:02 gkellogg has joined #rdf-star 21:08:14 gkellogg has joined #rdf-star 21:38:04 AndyS has joined #rdf-star 22:12:15 gkellogg has joined #rdf-star