Add minutes for W3C Solid CG meeting on 2025-09-24 #745
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,211 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2025-09-24:00:00Z | ||
| * Call: https://meet.jit.si/solid-cg | ||
| * Repository: https://github.com/solid/specification | ||
|
|
||
| ## Chair | ||
|
|
||
| * Michiel de Jong | ||
|
|
||
| ## Present | ||
|
|
||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * [Luke Dary](https://linkedin.com/in/lukedary) | ||
| * Matthieu Bosquet | ||
| * [Michal](https://id.mrkvon.org) | ||
| * Theo | ||
| * Tom Byrd | ||
| * Jesse W | ||
| * [Pierre-Antoine Champin](https://champin.net/#pa) | ||
| * Erich Bremer | ||
| * Rui Zhao | ||
|
|
||
| ## Regrets | ||
|
|
||
| * TallTed | ||
| * Hadrian | ||
|
|
||
| ## Scribes | ||
|
|
||
| * Matthieu | ||
| * Michiel | ||
|
|
||
| --- | ||
|
|
||
| ## Announcements | ||
|
|
||
| ### Meeting Guidelines | ||
| * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). | ||
| * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). | ||
| * No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. | ||
| * Join queue to talk. | ||
| * Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. | ||
|
|
||
| ### Participation and Code of Conduct | ||
| * [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) | ||
| * [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/) | ||
| * Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. | ||
| * If this is your first time, welcome! please introduce yourself. | ||
|
|
||
| --- | ||
|
|
||
|
|
||
| ## Introductions | ||
|
|
||
|
|
||
| ## Review Action items | ||
| * ACTION: HZ to reach out to contacts in Australia | ||
| * HZ not present | ||
| * ACTION: Theo to connect with muze.nl and PASS to gather feedback | ||
| * emails sent but no response yet | ||
| * eP: feedback would be about authz, what do they use for discovery, type indexes, etc. Document what practitioners use. | ||
| * JW: two comments: 1) make it easy for them to give feedback, ask specific questions. 2) this is an area where ODI can be better supporting in that conversation, e.g., through Solid World contacts to PASS. Let's not have too many crossed wires (CG, Practitioners, ODI, all asking the same questions). Let's follow a process, post on the specification and ODI matrix channels, and ODI can jump in where appropriate. | ||
| * eP: indeed it would be good to have a process, but maybe someone from their technical teams can join our CG meetings. | ||
| * Michiel: Maybe ODI can reach out to technical people to invite them to the CG meeting | ||
| * eP: and ask for feedback on the test suite usability | ||
| * ACTION: eP to follow up with Hadrian, Rui, and others to put it on the agenda as longer topic about tracking proposals for use cases | ||
| * eP: will be done (no time this past week) | ||
|
|
||
| ## Topics | ||
|
|
||
| ### Pull Requests | ||
|
|
||
| #### Publish SAI v0.1 | ||
| https://github.com/solid/specification/pull/743 | ||
|
|
||
| * SC: Reviews https://github.com/solid/specification/pull/743#pullrequestreview-3233700777 , https://github.com/solid/specification/pull/743#issuecomment-3303011300 . The proposal does not follow current CG Guidelines for publishing TRs. | ||
| * 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. | ||
| * MdJ: Any objections to publishing with RDF embedded in script tags | ||
| - MdJ: +1 | ||
| - PAC: +1 | ||
|
|
||
|
|
||
|
|
||
| * MdJ: there were no objections | ||
|
|
||
| #### 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 | ||
|
Comment on lines
+104
to
+106
There was a problem hiding this comment.
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 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
And that already covers it. It gives enough flexibility for anyone to express the "significant" information however they want.
Comment on lines
+90
to
+106
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 |
||
|
|
||
|
|
||
|
|
||
| #### add type for Class of Product | ||
| 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. |
||
| * MdJ: you could amend your PR but you could also spend your energy elsewhere where it's easier to make a dent | ||
|
|
||
| ### Tracking obstacles | ||
|
|
||
| ### Copyright violation claim in Solid CG | ||
|
|
||
| Proposed by SC. | ||
|
|
||
| * SC: I've documented the concern with data as best as I can at https://lists.w3.org/Archives/Public/public-solid/2025Sep/0005.html . The request for help from W3C Team is focused on the copyright claim itself. At the end of the email, I requested that the current CG chairs: | ||
|
|
||
| >to take this matter seriously, | ||
| discuss it in CG and take appropriate action, such as changing the | ||
| titles of the issues back to their original at this point, and take | ||
| additional measures on handling actions of non-CG participants by | ||
| coordinating with organisation hosting the `solid` GitHub organisation. | ||
|
|
||
| ### Governance of Solid CG assets and communication | ||
|
|
||
| Proposed by SC. | ||
|
|
||
| * SC: from https://github.com/solid-contrib/shapes/issues/5#issuecomment-3326730800 : | ||
| >Anything requiring Solid CG consensus must go through official communication channels. ODI neither governs nor controls W3C Solid CG's assets or work, nor does it determine what is "active" or "inactive" in any form. | ||
| * SC: If there is a disagreement on that expectation, it should be put in writing. If a detailed clarification is needed, a proposal can be put forwarded to the CG. | ||
|
|
||
| ### Proposal to fix invalid moves and archiving | ||
|
|
||
| Proposed by SC. | ||
|
|
||
| * SC: from https://github.com/solid-contrib/shapes/issues/5#issuecomment-3326730800 : | ||
| >I propose that the repositories be moved back to their original location, unarchived, and any settings changes undone. The CG as a whole can then decide what needs to be managed and coordinate with ODI. | ||
| * SC: Please unarchive repositories that were archived without CG's consent, e.g., https://github.com/solid/test-suite-panel/ | ||
| * Jesse: I can provide context. We at the ODI are going through a cleanup of github.org/solid to do a better job of going through issue backlogs. We posted a spreadsheet open for comment for over two weeks and only enacted prescribed actions on things that were not commented on. Sarven then requested things be moved back. I'd like to discuss whether some work items can be considered not active and moved to solid-contrib. | ||
| * eP: The least friction approach, I really appreciate the work to cleanup and groom GitHub. It is unfortunate Sarven didn't manage to be here today. solid-contrib is a bit unclear whether it is under ODI perview. We could archive things. | ||
| * Jesse: We will moderate solid-contrib and add the code of conduct. We're not saying we won't ever touch a repo there, it's just that we're not actively monitoring that space. I'd like to check whether archiving is ok. We need a CG consensus to confirm the CG is ok with archiving. | ||
| * 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 | ||
|
Comment on lines
+149
to
+152
There was a problem hiding this comment. Once again, ODI is hosting the That is at the core of the issue. If ODI needs to do housekeeping, e.g., needing to move a repository from 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. |
||
| * eP: I found the quote I looked for: | ||
| * SC: If there is a proposal to archive repos: shapes, test-suite-panel, authentication-panel, solid-wg-charter, I have no objection. However, do not move them to another org or rename. | ||
| * eP: Just to avoid the debate we can archive things, instead of moving. | ||
| * Jesse: For archiving, I am comfortable moving things back and archiving. | ||
|
|
||
| ### 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 |
||
| * 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. |
||
| * eP: Can we update the readme of both solid and solid-contrib GitHub orgs to have those details (stewardship/code of conduct). | ||
| * 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 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/ |
||
|
|
||
| ### Plans for `solid(-contrib)/shapes` repo | ||
| https://github.com/solid-contrib/shapes/issues/5#issuecomment-3325756416 | ||
|
|
||
| * MB: Do we have consensus to move this back to solid org and archive? | ||
| * eP: +1 | ||
| * MdJ: +1 | ||
| * JW: +1 | ||
| * RZ: +1 | ||
| * MdJ: there were no objections. | ||
|
|
||
| ### Plans for https://github.com/solid/test-suite-panel/ | ||
| Vote to archive | ||
| * MdJ: +1 | ||
| * eP: +1 | ||
| * JW: +1 | ||
| * RZ: +1 | ||
| * MdJ: there were no objections. | ||
|
|
||
| ### Plans for https://github.com/solid/authentication-panel/ | ||
| Vote to archive | ||
| * MdJ: +1 | ||
| * eP: +1 | ||
| * JW: +1 | ||
| * RZ: +1 | ||
| * MdJ: there were no objections. | ||
|
|
||
| ### Plans for https://github.com/solid/solid-wg-charter/ | ||
| Vote to archive | ||
| * MdJ: +1 | ||
| * eP: +1 | ||
| * JW: +1 | ||
| * RZ: +1 | ||
| * MdJ: there were no objections. | ||
|
|
||
| * SC: If there is a proposal to archive repos: shapes, test-suite-panel, authentication-panel, solid-wg-charter, I have no objection. However, do not move them to another org or rename. | ||
|
|
||
| ### Access Controls and Community Content Standards | ||
| https://hackmd.io/@dtb23/SyWsIvljll | ||
|
|
||
| * eP: Tom shared it last week, we could have initial discussion and look for ways to follow up. | ||
|
|
||
| ## Actions | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.