Weekly CG Meeting agenda and minutes: 2025-06-18

Signed-off-by: Hadrian Zbarcea <[email protected]>

Author: hzbarcea

meetings/2025-06-18.md

@@ -0,0 +1,159 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2025-06-18T14:00:00Z
+* Call: https://meet.jit.si/solid-cg
+* Chat: https://matrix.to/#/#solid_specification:gitter.im
+* Repository: https://github.com/solid/specification
+
+## Present
+
+* [Erich Bremer](https://ebremer.com)
+* Hadrian Zbarcea
+* Theo
+* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+* [Pierre-Antoine Champin](https://champin.net/#pa)
+* [uvdsl](https://github.com/uvdsl)
+* [TallTed // Ted Thibodeau Jr](https://github.com/TallTed) (he/him) [mastodon:@TallTed](https://mastodon.social/@TallTed) (OpenLinkSw.com)
+* Rui Zhao
+
+## Regrets
+---
+
+## 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.
+
+### Scribes
+
+* uvdsl
+
+---
+
+## Topics
+
+### Demo Solid Efforts with catalog data
+
+shapes and data: https://github.com/solid/catalog/
+demonstrated viewer: https://github.com/elf-pavlik/solid-efforts
+
+* eP: I can do a very quick demo
+* ... we discussed solid/catalog repo
+* ... it has shapes and data
+* ... and there is a viewer, where you can use forms
+* ... there is another viewer by @jeswr
+* ... and there is another one by me
+* ... There are different focus for different viewers in terms of audience
+* ... mine is more for specification authors
+* ... for example, in my viewer, we have "product classes"
+* ... which might come in handy in the efforts e.g. for the test suite
+* ... where we then can track like how much coverage we currently have.
+* ... Then there are other categories, like services etc, but also now we have some papers, e.g., the UMA paper
+* ... Jeff's effort / viewer was mostly on putting things into a taxonomy tree
+* ... The idea in my viewer is that we can jump between things and see dependencies and connections
+* ... for example, a product, e.g., SAI, has a dependency on library x.
+* ... and then I hope we can have also coverage reports on the products/services (e.g. from test suite)
+* ... Also, there could be an addition of "scopes" as in OAuth or with the shapes in SAI
+* ... If someone is interested in developing the data for these viewers (which have different audiences), please get in touch
+* TT: I do not see a feature to re-order these lists?
+* eP: Yes, right now, this is just to have some visualisation, not polished yet, I'll drop a link to the repo, please do open an issue!
+* TT: eP, could you link to the specific viewers into the minutes?
+
+### Test suite
+
+https://github.com/solid-contrib/specification-tests
+https://github.com/solid-contrib/conformance-test-harness
+https://app.gitter.im/#/room/#solid_test-suite:gitter.im
+
+* HZ: eP, is that your topic?
+* eP: We touched on it in the last meeting in the end.
+* ... Who is working on these?
+* ... I know that csarven has access; I think that MdJ also has access?
+* ... I think Pieter did most of the work
+* ... I opened two issues (link?), one on links and one on JSON-LD 1.1, 
+* ... I'd prefer not to update this myself, if there is someone who wants to help maintain it...?
+* ... I think the setup is nice but I do not have the capacity to do that.
+* ... Maybe Pieter wants to keep working on it, or we might find someone else?
+* HZ: In the first repo, the commits are over a year old, so no engagement there.
+* ... and for the second, there were only a few commits over the last year.
+* ... not sure who is responsible for these repos?
+* eP: CGs do not necessarily need to produce test suites, but WGs do, I think. 
+* ... So maybe the LWS WG could take over or use it as a base, then it might be beneficial to both
+* HZ: I think that Solid CG is one part to incubate the work of LWS, and we should find some capacity in the CG.
+* EB: I agree with eP, I think it makes sense to join forces.
+* ... Generally, I am interested to see if I could use this in my own work, so I could certainly take a look at it.
+* PAC: Anything that the CG can support, it is welcome by the WG. But I can understand the problems the CG faces. I think it may be a good idea to raise awareness in the WG - probably/maybe/or not the WG might or not decide to fork it. idk.
+* HZ: Actually, ODI took over stewardship, so maybe ODI could help find capacity.
+* eP: @eBremer, I got it working for SAI - there are some gotchas but if you just you use the usual tests, then it should be managable
+* ... I dropped the link to the test suite gitter - please ask questions!
+* ... on the forking, why? What is the issue on transfering ownership?
+* PAC: It depends how much the CG is still involved, maybe the WG would like not be tied to an pre-existing repo. 
+* HZ: @jeswr, we have these test harness repos, if these need to be maintained, maybe the LWS WG could use them or ODI could help find capacity to maintain it.
+* eP: We should also double check with MdJ on migration.
+* JW: I could see how ODI could support the work - on the LWS, it is unclear on how much of an alignment of LWS to Solid is
+* HZ: Is there an ask by ODI for the test harness to be supported?
+* JW: Iirc, the Karate framework was established by Pete Edward by Inrupt, does Inrupt have a commitment to maintain the repo?
+* HZ: Do you want me to find out?
+* JW: Yes.
+ACTION: HZ to reach out to Inrupt to understarstand the commitment to maintain the repo
+* eP: On the separation on test harness and test suite, afaik, the harness should be able to run any test suite - so maybe the LWS test suite could still re-use the harness as a runtime.
+* JW: If the harness is general enough to be applicable to other RDF-based spec, then maybe it is also of interest to the W3C?
+* PAC: W3C does not maintain any such kind of infrastructure as these differ vastly between groups.
+* eP: For browsers, there is a platform — but for RDF-related groups possibly could benefit from a shared test setup. While there are distinct groups of gropus, I also see potential for certain groups to benefit.
+* PAC: There might be caveats, but of course, if more people can benefit, that would be okay.
+* TT: I have raised the flag on this before: 
+* ... LWS would be one component in the Solid-based solution.
+* ... Solid and LWS are distinct and not synonymous
+
+### Publishing reports
+
+* eP: Related to above, I would like to publish metadata with test requirements used by the test suite. I don't want to use RDFa, is `<script>` island the only alternative or we can use content negotiation or `describedBy` description resources?
+* ... Requirements have their own meta-data
+* ... my main question:
+* ... only 3 specs use these meta-data
+* ... the ones that csarven edited using RDFa
+* ... I do not like using RDFa
+* ... I would rather use something else 
+* ... question is, what is the cleanest way to publish that meta-data
+* ... e.g. content-negotiation (for turtle for example)
+* ... or link header describedBy
+* ... or script tag
+* TT: I would not recommend RDFa for use anywhere that is not already HTML and needs RDF added in there (though `<script>` islands may be a better solution)
+* ... any of the RDF syntaxes are fine, whether that is handled dynamically by content negotiation or manually on the publication does not really matter in my opinion
+* eP: Question. For the drafts (LWS?), is there a way to have content negotiation in the W3C setup?
+* PAC: I think I remember github pages does not support content negotiation.
+* eP: I thought the Working Draft is under W3C?
+* PAC: I dont think there is precedence under /TR/ - there may be other locations where this happens - but /TR/ is special, I do not know.
+* TT: I believe if you request a given datatype, you would get that back.
+* PAC: Does the process for publishing on /TR/ provide the mechanisms to support this content negotiation?
+* TT: Ask (insert responsible persons name), and you will find out...
+* eP: @PAC, could you find out about that? Then, the Solid CG could also benefit from that for the CG group notes.
+* eP: @jeswr, what is your take on this?
+* JW: Not sure how they are currently published - I recall Verecel to be used? Then there would be middleware to use to do that.
+* ... but it looks that it is direct Github pages deployment.
+* ... if W3C has a setup to support this, then it should be reasonable to follow their lead.
+
+### CG Principles and Framework for Proposals
+
+* eP: I would like to PR text we worked on with Ian to https://github.com/w3c-cg/solid
+* ... and then iterate in the repo on it
+* ... to keep it moving?
+* ... Are there any objects to that roadmap
+* JW: +1
+* HZ: +1
+* PAC: +1
+* EB: +1
+* CB: +1
+
+ACTION: eP to make a PR
+