Add minutes for W3C Solid CG meeting on 2025-09-24 #745
Conversation
Documented the W3C Solid Community Group meeting held on September 24, 2025, including attendance, action items, and discussions on various topics.
| * eP: Thanks for all your comments and I agree it is not the best moment to change things, I'll update the PR to reflect the consensus on embedding RDF and on URLs (date will not be publish, rather snapshot because of time to review PR). | ||
|
|
||
| ACTION: eP to update the PR |
There was a problem hiding this comment.
I'll update the PR to reflect the consensus on embedding RDF and on URLs
That's unclear to me based on what's minuted and the discussion / context before. The only "consensus" that I see above is that there is no objection to you using script block in the SAI spec.
I don't see anything else beyond that has anything to do with the guidelines.
The Guidelines for Publication already includes:
https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#publication-rules
Follow the Linked Data design principles. Give all significant units of information, e.g., concepts, requirements, an identifier, and provide a description using a concrete RDF syntax (see also Spec Terms).
And that already covers it. It gives enough flexibility for anyone to express the "significant" information however they want.
| #### add semver version of publishing | ||
| https://github.com/w3c-cg/solid/pull/24 | ||
|
|
||
| * SC: Review: https://github.com/w3c-cg/solid/pull/24#pullrequestreview-3235967032 . The proposal lacks evidence of any confusion, and does not justify introducing unnecessary complexity. The current practice in the CG Guideline is based on W3C publication rules that's already familiar to the W3C community. | ||
|
|
||
| * MdJ: I have always been in favour of semver. I was pushing for tagging Solid .7 .8 etc. I see people want to use dates. They have advantage of timeline. But if document is already versioned it makes sense to use it in the URL as well. Whatever you use for spec and test suite, I think it was always looking at semver. | ||
|
|
||
| ACTION: eP to check how test suite uses versions | ||
|
|
||
| * Matthieu: I would tend to advise consistency across namespace. If it has been done one way, there is a good case to keep it this way even if it isn't perfect. | ||
| * Pierre Antoine: I share Matthieu's opinion that if we have two ways of doing things it is a source of confusion. I see your opinion about having semantic versioning vs dates being confusing but I don't know and it seems to have worked well for W3C so far. I think in that sense there is a good point for keeping things as they are but I don't feel very strong about it either. | ||
| * Michiel: Ietf has versions that cannot be changed. W3C seems less prescriptive about it. The spec document could be versioned with a date and the semantic version | ||
| * Pierre Antoine: Semantic versioning is designed for software (it seems inadequate if a bit pedantic to version specs this way). The second point is we don't use semver in W3C which is different from the date we use because one version can have several drafts with separate dates. | ||
| * Erich: For publications, I would go dates and wholeheartedly in favour of consistency. | ||
| * eP: Thanks for all your comments and I agree it is not the best moment to change things, I'll update the PR to reflect the consensus on embedding RDF and on URLs (date will not be publish, rather snapshot because of time to review PR). | ||
|
|
||
| ACTION: eP to update the PR |
There was a problem hiding this comment.
Just to be clear here, the main concern about versioned snapshot was about the URL pattern that is used for it. We've been following the same pattern as W3C publication rules. As mentioned, that's all detailed at https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#publishing-a-technical-report
That is orthogonal to author-level content such as the publication date, spec's semantic version, or even the CG-DRAFT/FINAL status. "Dates" are not being argued for replacement for semantic versioning or CG report status.
So, as it stands I don't see anything new or controversial to change the Guidelines.
There was a problem hiding this comment.
I responded in #743 (comment) that I'm going to update URLs
I'll try to do it later today or tomorrow.
| https://github.com/solid/vocab/pull/97 | ||
|
|
||
| * SC: There are several issues with this proposal as extensively outlined in the reviews that I've provided. The proposal misinterprets `requirementSubject` (source: me, author), as well as goes counter to existing use of the term in publications (such as in Solid Protocol) - in a sense, the proposal attempts to hijack its actual use. The proposal also duplicates an existing solution that already provides a way to discover classes of products. | ||
| * Matthieu: vocab work is hard |
There was a problem hiding this comment.
I agree. It is indeed hard, and it is also a fraction of the work. Publishing / improving specs along the way, and building applications using that stuff is the other hard work.
What's in the vocab generally reflects use to date.
| * Michiel: I value the work Jesse is doing here and we should let him move and archive as makes sense. Whatever is clearer to readers. | ||
| * Jesse: I looked at the issue and Sarven asked to unarchive. | ||
| * Michal: I didn't understand what Sarven said. I'm not sure if solid and solid-contrib belongs to CG or ODI? | ||
| * Jesse: ODI has legal ownership of solid GitHub org and responsibility to monitor those repos. The only one deffered to the CG is solid/specification |
There was a problem hiding this comment.
Once again, ODI is hosting the solid GH organisation, and the CG has repositories there. As far as I'm aware, there is an understanding that the CG retains control over its repositories. ODI's hosting of the solid GH organisation does not imply that ODI decides in any form what is a CG work item or what is active or inactive, or anything in between.
That is at the core of the issue. If ODI needs to do housekeeping, e.g., needing to move a repository from solid org to elsewhere, that's perfectly fine. The CG needs to be informed, the CG needs to decide where it wants to move it to. The CG also decides whether something should be archived or not. The whole thing about discussion and decision being taking in some corner ODI channel is invalid and irrelevant. Especially when that is not at all communicated widely with the whole CG. The CG chairs can communicate ODI's needs to the CG, and we can go from there.
Not everyone is in that ODI channel and no one is required to either. On a related note, being a CG participant (having signed W3C stuff) does not imply that the same individual also signs ODI stuff.
| ### Ownership Question | ||
|
|
||
| * Michal: I don't understand the meaning of legal ownership (especially for solid-contrib and practitioners things). | ||
| * Jesse: We are moderating all repository on the solid and solid-contrib GitHub org and all codebases are MIT license. |
There was a problem hiding this comment.
As far as I know solid-contrib is loosely managed by the Solid community, not by any particular entity, such as ODI. But if there is some text that states that ODI has "ownership" on solid-contrib, can you link to it?
|
|
||
| * Michal: I don't understand the meaning of legal ownership (especially for solid-contrib and practitioners things). | ||
| * Jesse: We are moderating all repository on the solid and solid-contrib GitHub org and all codebases are MIT license. | ||
| * Michiel: We can think of it as stewardship of these repos rather than ownership. |
There was a problem hiding this comment.
That was my view as well. And that is also why ODI does not have authority on moving things, archiving. It has the necessary privileges to admin the space but as hosts, CG material is decided by the CG.
| * Jesse: If an org like ODI is not moderating solid-contrib, we will hit issues where something such as solid server are not moderated. From a pragmatic standpoint, we just want consistent moderation of "official"/"popular" repos. | ||
| * Michal: I'm just thinking from the point of view of moving repos and admin rights. | ||
| * Jesse: I will come to the practitioners group to continue the conversation. | ||
| * eP: It should be transparent in the readme of the organisations who is admin of the orgs. That will help. |
There was a problem hiding this comment.
I'm not sure about blasting ODI everywhere. They are the admins on solid org for example but I don't think it makes any sense that something like solid/specification needs to mention ODI. The README there is already clear that it is W3C Solid CG workspace and the W3C Conduct etc. For other non-CG repos under solid or elsewhere, I agree with you.
There was a problem hiding this comment.
I was referring to README of a github org https://github.blog/changelog/2021-09-14-readmes-for-organization-profiles/
| * eP: Editors should publish how they feel comfortable. I used a script tag to embed some RDF. We should try to embed RDF in HTML because content negotiation on W3.org is problematic. | ||
| * eP: I remember TBL working with the same solution. I have a `<script type="application/ld+json">` in the HTML to add RDF. | ||
| * eP: I only added minimum description, nothing that is requirements for tests. I started using the test harness for SAI and will add requirements after that works. | ||
| * MdJ: OK, as long as you're aware of the value of linking from the test suite to spec paragraphs in a machine readable way, and PAC is OK with it then I am too. |
There was a problem hiding this comment.
I don't understand PAC's role or significance. Or did you mean that as a personal preference?
There was a problem hiding this comment.
I didn't remember if https://www.w3.org/TR/json-ld11/#embedding-json-ld-in-html-documents was normative and PAC confirmed it was. I believe he also +1 in the chat to having this way of publishing spec descriptions available. /cc @pchampin
There was a problem hiding this comment.
As I've mentioned in #745 (comment) , the current Guidelines ( https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#publication-rules ) leaves plenty of room and flexibility for authors to publish how they want to:
Follow the Linked Data design principles. Give all significant units of information, e.g., concepts, requirements, an identifier, and provide a description using a concrete RDF syntax (see also Spec Terms).
This is also the case in https://solidproject.org/ED/qa .
But I have to ask, are you emphasising all of this so to ensure the script blocks are the only way to express the RDF graph of a specification? Like, do you wish to see that the guidelines should be updated so that only script is allowed and RDFa is not? Is that your end goal here? Or is there something in the current guidelines that you find inadequate?
There was a problem hiding this comment.
I want to leave it to the editors to choose among available standard ways of embedding RDF in HTML. There's also https://www.w3.org/TR/turtle/#in-html (this one was the non-normative one). So RDFa and <script /> tags are perfectly fine. I didn't get your confirmation on #743 (comment) so I requested call for rough consensus just in case it was also a part of your change request. It looks that there was not issue there and your commments on the PR related to the choice of embedding method were not part of the change request.
There was a problem hiding this comment.
tl;dr: Expressing RDF is optional, and the choice of embedding or providing alternative serializations is up to contributors.
If solidproject.org actually ran on a Solid server - I realise that is a wild idea now that we are in 2025, re solid/solidproject.org#248 ), then the server could do conneg. So, if anyone wants to write provide a Turtle or JSON-LD serialization of the spec, they can.
I mean.. that's all fine. I don't find the additional work, machinery, and additional points of failure to worthwhile, but to each to their own. I use RDFa because I'm also looking at it from how applications can help to author and publish specifications - a lot like how Solid aims to be. Anything besides RDFa requires a far more complex setup and out-of-band agreement in order to be able to update both the human- and the machine-readable parts or aspects of the specification. But happy to be shown otherwise if anyone wants to go through the trouble of creating a Solid-compatible authoring tool that can manage multiple serializations or can read/write and synchronise duplicate content in a script block meanwhile keeping the specifications human- and machine-readable.
Documented the W3C Solid Community Group meeting held on September 24, 2025, including attendance, action items, and discussions on various topics.