15:56:56 <RRSAgent> RRSAgent has joined #rdf-star
15:57:00 <RRSAgent> logging to https://www.w3.org/2025/05/29-rdf-star-irc
15:57:14 <ktk> meeting:  [Ping timeout: 180 seconds]
15:57:23 <ktk> meeting RDF-star WG biweekly focused meeting
15:57:29 <ktk> meeting: RDF-star WG biweekly focused meeting
15:57:47 <ktk> Agenda: https://www.w3.org/events/meetings/3145be7b-99e7-49af-90b0-aee845dc7b2d/20250529T120000/
15:57:47 <agendabot> clear agenda
15:57:47 <agendabot> agenda+ Unstar algorithm and upcoming the RDF Concept CR -> 1 https://lists.w3.org/Archives/Public/public-rdf-star-wg/2025May/0011.html
15:57:47 <agendabot> agenda+ Expected behavior of systems when profile does not match used features -> 2 https://github.com/w3c/rdf-star-wg/issues/161
15:57:48 <agendabot> agenda+ What advice to put in RDF specs about the handling of version labels. -> 3 https://github.com/w3c/rdf-concepts/issues/205
15:57:50 <agendabot> agenda+ Acknowledge the two purposes of this document -> 4 https://github.com/w3c/rdf-schema/issues/45
15:57:53 <agendabot> agenda+ Different parsing of the same absolute IRI with or without base IRI -> 5 https://github.com/w3c/rdf-turtle/issues/89
15:57:58 <ktk> RRSAgent, draft minutes
15:57:59 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html ktk
15:58:01 <ora> ora has joined #rdf-star
15:58:01 <gkellogg> present+
15:58:02 <ktk> RRSAgent, make log public
15:58:11 <pfps> present+ but only on IRC
15:58:44 <AndyS> AndyS has joined #rdf-star
15:58:51 <niklasl> present+
15:58:56 <ora> present+
15:59:00 <ktk> regrets+ olaf, tl, AZ
15:59:10 <ktk> Chair: ora
15:59:22 <james> present+
15:59:47 <gkellogg> scribe+
16:00:36 <ktk> present+
16:00:44 <AndyS> present+
16:01:23 <eBremer> eBremer has joined #rdf-star
16:01:24 <eBremer> present+
16:02:28 <enrico> enrico has joined #rdf-star
16:02:42 <enrico> present+
16:02:53 <william-vw> william-vw has joined #rdf-star
16:02:56 <william-vw> present+
16:03:08 <gkellogg> zakim, next item
16:03:08 <Zakim> agendum 1 -- Unstar algorithm and upcoming the RDF Concept CR -> 1 https://lists.w3.org/Archives/Public/public-rdf-star-wg/2025May/0011.html -- taken up [from agendabot]
16:03:19 <Souri> Souri has joined #rdf-star
16:03:23 <Souri> present+
16:03:35 <gkellogg> ora: would prefer to wait for pchampin for this.
16:03:41 <gkellogg> zakim, close item 1
16:03:41 <Zakim> agendum 1, Unstar algorithm and upcoming the RDF Concept CR -> 1 https://lists.w3.org/Archives/Public/public-rdf-star-wg/2025May/0011.html, closed
16:03:44 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html TallTed
16:03:50 <Zakim> I see 4 items remaining on the agenda; the next one is
16:03:50 <Zakim> 2. Expected behavior of systems when profile does not match used features -> 2 https://github.com/w3c/rdf-star-wg/issues/161 [from agendabot]
16:03:50 <gkellogg> zakim, next item
16:03:50 <Zakim> agendum 2 -- Expected behavior of systems when profile does not match used features -> 2 https://github.com/w3c/rdf-star-wg/issues/161 -- taken up [from agendabot]
16:04:01 <Dominik_T> Dominik_T has joined #rdf-star
16:04:08 <Dominik_T> present+
16:04:10 <TallTed> present+
16:04:12 <ktk> scribe+
16:04:36 <ktk> gkellogg: There are a number of ways to specify a version you want.
16:04:48 <ktk> ... one of them are HTTP accept headers.
16:05:32 <TallTed> previous meeting: https://www.w3.org/2025/05/23-rdf-star-minutes.html
16:05:32 <TallTed> next meeting: https://www.w3.org/2025/05/30-rdf-star-minutes.html
16:05:44 <ktk> ... We should talk about how implementations are expected to behave.
16:06:03 <ktk> ... We need to say something about this, even if we cannot mandate it.
16:07:00 <gkellogg> ora: Is this an error? we can write conformance tests. But, what is the expected behavior of consumers?
16:07:07 <ktk> ora: For reading, the questions is how is the system behaving for consuming.
16:07:13 <ktk> s/questions/question/
16:07:37 <ktk> ... gkellogg you also say we have a potential solution for the text direction downgrade?
16:07:47 <ktk> gkellogg: yes, there is a proposed solution from JSON-LD.
16:08:33 <ktk> ... The system is recommended for years by the i18n WG
16:08:49 <ktk> ora: could we simply refer to an appropriate JSON-LD document, or what do we need?
16:09:01 <ktk> ... gkellogg you are suggesting an informative part.
16:09:08 <ktk> gkellogg: yes we could do that.
16:09:50 <gkellogg> ora: the minimum for an informative description would be to refer to JSON-LD for use of the i18n namespace for language/text direction?
16:09:53 <AndyS> q+
16:09:58 <ora> ack AndyS
16:09:59 <gkellogg> s/direction?/direction./
16:10:45 <gkellogg> AndyS: If we use the version as a declaration of intent, we should realize that we're also creating a system for the future. A future version of Turtle could have syntax and/or semantic changes.
16:11:19 <gkellogg> ... The other interesting use is that we now have a way of making a declaration of the expectations for the data.
16:11:46 <gkellogg> ... I don't think we can mandate the unstar algorithm, which would require that it be normative.
16:12:10 <gkellogg> ... If we keep things on the level of advice, we're in the same situation we are today.
16:12:36 <gkellogg> ... Unstar would be something that could be used be a publisher.
16:12:59 <niklasl> +1 for advisory & informative (and for the points re. conneg)
16:13:01 <gkellogg> ... ACCEPT requests are advisory, and we should not do more.
16:13:13 <gkellogg> ora: we shouldn't mandate specific behavior.
16:13:31 <gtw> present+
16:13:34 <TallTed> s/meeting RDF-star WG biweekly focused meeting//
16:13:48 <gkellogg> ... What about failing, rather than returning something wrong.
16:13:49 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html TallTed
16:13:55 <niklasl> q+
16:14:40 <ora> ack niklasl
16:14:42 <gkellogg> AndyS: It can depend on usage of if it should generate an error; large documents could require a lot of work before you knew it was using inappropriate features.
16:15:08 <gkellogg> niklasl: If you concatenate multiple files and one contains an explicit version that is lower than others, it would be confusing.
16:15:33 <james> q+
16:15:40 <ora> ack james
16:15:49 <gkellogg> ... generally, if you use VERSION 1.2, you should be able to take anything, but if you add 1.1, it would be inconsistent.
16:16:04 <gkellogg> james: What would one expect if you're not able to satisfy the request.
16:16:39 <gkellogg> ... Would it be fair for the recommendation to require that systems announce the version they're sending back.
16:17:10 <gkellogg> ora: There are multiple things to figure out.
16:17:55 <AndyS> q+
16:17:56 <ktk> q+
16:17:58 <gkellogg> ... Can we use as guidance things that already exist? for example, what implementations do when there's a syntactic error.
16:18:00 <ora> ack AndyS
16:18:29 <gkellogg> AndyS: On the web, the responsibility is with the receiver. You have to be defensive if you care.
16:18:52 <gkellogg> ora: consuming RDF isn't always a transaction.
16:18:56 <ora> ack ktk
16:19:14 <gkellogg> ktk: Are we talking just about content negotiation, or something more.
16:19:43 <gkellogg> ... In content negotiation, you can say 406 "Not Acceptable". We don't need to redefine content negotiation.
16:20:21 <gkellogg> AndyS: We can put the advice about using unstar in the unstar document, so that it claims it can be used to satisfy such requests.
16:20:23 <ktk> q+
16:20:26 <ora> ack ktk
16:21:03 <gkellogg> ktk: I implemented content negotiation for RDF, and I realized that many implementations handle such headers differently, so it's not trivial.
16:21:27 <gkellogg> AndyS: The amount of stuff that is returned text/plain no mater what you ask for is crazy.
16:21:52 <gkellogg> ... People just put files up on web servers, and they don't have any further knowledge about media types.
16:22:03 <gkellogg> ... Not so much a problem for results.
16:22:24 <gkellogg> ora: As spec writers, we need to minimally offer advice for producers and consumers.
16:22:42 <gkellogg> ... Also, we need to decide where does it go.
16:23:02 <gkellogg> gkellogg: We don't have a "best practices" document.
16:23:16 <ktk> q+
16:23:21 <gkellogg> ora: What else could go in such a document? Can we collect all the ideas to put into a single document.
16:23:37 <niklasl> q+
16:23:42 <gkellogg> AndyS: The IRI advice note in concepts could go into that document.
16:24:08 <ora> ack ktk
16:24:18 <gkellogg> ktk: Would it be wrong to go in the Primer? It's mostly for consumers, but could goo there as well.
16:24:23 <ora> ack niklasl
16:24:43 <gkellogg> niklasl: The Primer is smaller than Concepts, but it might take on more.
16:25:08 <gkellogg> ... Uses of fragment identifiers might go in there, and more advice on RDF documents and syntaxes.
16:25:28 <gkellogg> ... But, it could be a best practices that is distinct from the primer.
16:25:46 <Dominik_T> rrsagent, draft the minutes
16:25:48 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html Dominik_T
16:25:57 <gkellogg> ora: At one extreme, we could leave them in existing documents, at the other, create new documents.
16:26:13 <AndyS> q+
16:26:13 <gkellogg> ... This could be rather large, so it may make sense to move in a separate document
16:26:15 <gkellogg> q+
16:26:18 <ora> ack AndyS
16:26:39 <gkellogg> AndyS: A proposal might be to put an info note in Concepts now, and see how much it grows.
16:26:49 <ora> ack gkellogg
16:26:51 <gkellogg> ... We can then review how things are looking closer to CR.
16:27:02 <ktk> scribe+
16:27:27 <ktk> gkellogg: different groups have a primer and a best practices, JSON-LD for example.
16:27:36 <ktk> ... They serve different audiences.
16:27:50 <niklasl> I agree. The primer "is designed to provide the reader with the basic knowledge required to effectively use RDF". (From its Abstract.)
16:28:10 <ktk> ... It's also a place to point to other best practices documents, like i18n.
16:28:34 <gkellogg> ora: First thing to do is to produce the content and put it in some document, then we can decide how to move anything around.
16:28:43 <ktk> scribe-
16:29:11 <gkellogg> q+
16:29:19 <ora> ack gkellogg
16:29:25 <ktk> scribe+
16:29:48 <ktk> gkellogg: I can write down some things we agree on.
16:32:09 <niklasl> +1 for Postel's law
16:32:11 <gkellogg> ora: might be a good idea to reinforce Postel's Law in our documents.
16:33:00 <gkellogg> ... We need some text to look at that we can decide on.
16:33:15 <james> an operator, such as fetch in node, is very lenient. it just passes incompatible content through _ with the actualy content type_ and leaves it to the application to handle the consequences.
16:33:22 <ktk> gkellogg: I can do a PR that we can use for discussion.
16:33:28 <ktk> ora: sounds good.
16:33:37 <ktk> scribe-
16:33:41 <gkellogg> zakim, next item
16:33:41 <Zakim> agendum 3 -- What advice to put in RDF specs about the handling of version labels. -> 3 https://github.com/w3c/rdf-concepts/issues/205 -- taken up [from agendabot]
16:34:13 <gkellogg> gkellogg: This is part of the previous issue.
16:34:16 <gkellogg> zakim, next item
16:34:16 <Zakim> agendum 3 was just opened, gkellogg
16:34:21 <gkellogg> zakim, close item 3
16:34:21 <Zakim> agendum 3, What advice to put in RDF specs about the handling of version labels. -> 3 https://github.com/w3c/rdf-concepts/issues/205, closed
16:34:23 <Zakim> I see 2 items remaining on the agenda; the next one is
16:34:23 <Zakim> 4. Acknowledge the two purposes of this document -> 4 https://github.com/w3c/rdf-schema/issues/45 [from agendabot]
16:34:24 <gkellogg> zakim, next item
16:34:24 <Zakim> agendum 4 -- Acknowledge the two purposes of this document -> 4 https://github.com/w3c/rdf-schema/issues/45 -- taken up [from agendabot]
16:34:40 <Dominik_T> q+
16:34:45 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html TallTed
16:35:08 <ora> ack Dominik_T
16:35:28 <gkellogg> Dominik_T: I agree with pchampin on this discussion. We should clearly describe the main purposes of the document.
16:35:50 <gkellogg> ... No matter what we decide on the name or scope, it is a big change in structure and content.
16:36:10 <gkellogg> ... The changes are major and will need careful planning, and can't loose important content.
16:36:45 <gkellogg> ... I'm willing to start a PR, but not sure how to do this properly. Smaller PRs are hard, but one bit PR may make it hard to follow.
16:36:59 <gkellogg> ora: Can we have a plan in advance so we know?
16:37:29 <gkellogg> ... With a plan, we could have separate PRs and annotate the plan to point to those PRs.
16:37:46 <gkellogg> Dominik_T: I can start creating such a plan in GH.
16:38:14 <gkellogg> ... I think it will be hard; we need to puzzle the structure, and that make it hard to decide how to structure.
16:38:18 <pfps> RDF 1.1 Schema already includes sections that are not about the rdfs namespace, so I don't view this as a change to the document, just an ack that it covers more than the rdfs namespace.
16:38:30 <gkellogg> ora: Then there's the potential renaming of the document.
16:39:23 <AndyS> q+
16:39:28 <ora> ack AndyS
16:39:28 <gkellogg> ... If I understand pfps's comment, we would explain the document in the introduction/abstract
16:40:01 <gkellogg> AndyS: A suggestion about datatypes in the rdf: namespace, what do people think about moving the three datatypes from concepts here.
16:40:08 <niklasl> Sounds good to me.
16:40:08 <pfps> Yes, in my view all that is required is to change the abstract and the introduction, and probably not by very much.
16:40:32 <gkellogg> ... rdf:JSON, rdf:HTML, etc are defined in Concepts, but might go to Schema.
16:40:52 <gkellogg> gkellogg: we have inbound links to those datatypes in concepts.
16:41:24 <gkellogg> ora: Even if we put most of the content in schema, they don't need to go away entirely.
16:41:26 <pfps> rdf:HTML and rdf:XMLLiteral were already in RDF 1.1 Schema, so there is precedent.
16:42:41 <gkellogg> ora: Do we need a decision on renaming the document?
16:43:21 <ora> STRAWPOLL: Rename RDF Schema to RDF Vocabularies?
16:43:23 <gkellogg> gkellogg: Without some specific support, I'd say leave it as is.
16:43:25 <ora> -1
16:43:26 <william-vw> +1
16:43:29 <Souri> -1
16:43:30 <james> -1
16:43:30 <gkellogg> -0.5
16:43:31 <Dominik_T> -1
16:43:32 <enrico> -0.9
16:43:34 <ktk> 0
16:43:35 <pfps> -0.5
16:43:35 <AndyS> 0
16:43:37 <eBremer> +0
16:43:41 <niklasl> +0.25
16:43:45 <gtw> +0
16:43:53 <TallTed> -0.9
16:44:56 <gkellogg> william-vw: I don't see an issue with renaming it to "RDF Vocabularies", but I don't think it would be confusing if there's a note about renaming.
16:45:18 <gkellogg> ... URL changes are solvable.
16:45:19 <gkellogg> q+
16:45:24 <ora> ack gkellogg
16:46:23 <gkellogg> gkellogg: W3C has infrastructure for redirecting shortnames.
16:46:55 <gkellogg> niklasl: I'm not sure it would have a big impact to change it, particularly over time. It would have been nice if it had been Vocabulary all along.
16:47:11 <gkellogg> ... Then there's the "Vocabulary" vs "Ontology" discussion.
16:47:36 <gkellogg> ora: "Schema" is greek, we'd be forced to use "Schemata" for the plural.
16:47:52 <gkellogg> ... I suggest we defer this until the end, but we have other things to do.
16:48:33 <gkellogg> ... I think a plan for what to do will emerge as we work further.
16:48:38 <gkellogg> zakim, next item
16:48:38 <Zakim> agendum 5 -- Different parsing of the same absolute IRI with or without base IRI -> 5 https://github.com/w3c/rdf-turtle/issues/89 -- taken up [from agendabot]
16:49:15 <Dominik_T> rrsagent, draft the minutes
16:49:16 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html Dominik_T
16:49:57 <ktk> regrets+ pchampin
16:51:13 <AndyS> q+
16:51:24 <ora> ack AndyS
16:51:57 <gkellogg> AndyS: An additional factor is that RFC 3986 says that dot segments are only intended at the beginning of a path.
16:52:16 <gkellogg> ... And, the resolution algorithm has a "strict" and "lax" description.
16:52:31 <gkellogg> ... Even just coming from 3976 there are options for us to consider.
16:52:46 <gkellogg> ora: What happens if we don't do anything?
16:53:08 <gkellogg> ... I'd like to avoid breaking existing RDF systems. On the other hand, there's going to be trouble either way.
16:53:32 <gkellogg> AndyS: It's only when you have dots within a IRI that has a scheme.
16:54:31 <niklasl> q+
16:54:36 <ora> ack niklasl
16:54:39 <gkellogg> ... In the advice note, we should mention something about dots, whatever we do. Jena can do either, and no one has ever really noticed.
16:55:16 <AndyS> q+
16:55:20 <gkellogg> niklasl: Thinking about URIs coming up with diffs and the like, that uses multiple dots. If an IRI looks like it's resolved, I wouldn't touch it.
16:55:43 <ora> ack AndyS
16:55:45 <gkellogg> ... We're ambiguous now, and it's not clear if a "resolved" IRI must still be rsolved.
16:56:31 <gkellogg> AndyS: In the IRIs note, we have a section intended for something else about minting IRIs. We suggest to normalize by eliminating "/." and "/..".
16:56:33 <AndyS> rdf-concepts: -- """Normalize IRIs to remove "/./" and "/../" in the path component of an IRI."""
16:56:50 <gkellogg> ora: Can we put in something to normalize that to be consistent.
16:56:50 <Tpt> q+
16:57:03 <ora> ack Tpt
16:57:23 <gkellogg> Tpt: I'm not sure we need to be consistent, as we say you should not use problematic IRIs
16:57:50 <gkellogg> ... When there are dots in IRIs that are already absolute, systems should not resolve them.
16:58:13 <niklasl> +1 kind of a "if you do, we assume you might have your reasons"
16:58:13 <gkellogg> ktk: Do we agree that engines should all behave the same way.
16:58:56 <niklasl> q+
16:58:59 <AndyS> q+
16:59:03 <ora> ack niklasl
16:59:03 <gkellogg> gkellogg: do Turtle parsers always resolve?
16:59:18 <gkellogg> niklasl: Can we assess what data in the wild would change?
16:59:30 <ora> ack AndyS
16:59:30 <AndyS> Example -- <http:abc> base <http://example/>
16:59:33 <gkellogg> ... Implementations behave differently, and we don't know what the data says.
16:59:58 <gkellogg> AndyS: An example that doesn't use dots or slashes.
17:00:21 <gkellogg> ora: I'll send regrets for next week, at Semantic Arts event.
17:00:27 <gkellogg> ktk: Me too :)
17:00:42 <gkellogg> regrets+ pchampin
17:00:50 <Dominik_T> rrsagent, draft the minutes
17:00:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html Dominik_T
17:01:07 <gkellogg> ktk: We'll send an email with an agenda or a cancelation by next wednesday.
17:01:26 <gkellogg> rrsagent, write minutes
17:01:26 <RRSAgent> I'm logging. I don't understand 'write minutes', gkellogg.  Try /msg RRSAgent help
17:01:43 <ktk> RRSAgent, draft minutes
17:01:45 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html ktk
17:02:07 <gkellogg> zakim, end meeting
17:02:07 <Zakim> As of this point the attendees have been gkellogg, but, only, IRC, niklasl, ora, james, ktk, AndyS, eBremer, enrico, william-vw, Souri, Dominik_T, TallTed, gtw
17:02:10 <Zakim> RRSAgent, please draft minutes
17:02:11 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-rdf-star-minutes.html Zakim
17:02:17 <Zakim> I am happy to have been of service, gkellogg; please remember to excuse RRSAgent.  Goodbye
17:02:17 <Zakim> Zakim has left #rdf-star
17:08:06 <pfps> pfps has left #rdf-star
17:22:48 <gkellogg> gkellogg has joined #rdf-star
17:31:01 <gkellogg> gkellogg has joined #rdf-star
19:00:34 <gkellogg> gkellogg has joined #rdf-star
19:24:53 <gkellogg> gkellogg has joined #rdf-star
20:23:10 <gkellogg> gkellogg has joined #rdf-star
21:50:59 <gkellogg> gkellogg has joined #rdf-star
22:07:21 <gkellogg> gkellogg has joined #rdf-star
22:14:05 <gkellogg> gkellogg has joined #rdf-star
22:42:26 <gkellogg> gkellogg has joined #rdf-star
23:00:10 <gkellogg> gkellogg has joined #rdf-star