Add 2023-03-01 agenda and minutes

meetings/2023-03-01.md

@@ -0,0 +1,137 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2023-03-01T14:00:00Z
+* Call: https://meet.jit.si/solid-cg
+* Chat: https://gitter.im/solid/specification
+* Repository: https://github.com/solid/specification
+* Status: Published
+
+## Present
+* [Sarven Capadisli](https://csarven.ca/#i)
+* [Virginia Balseiro](https://virginiabalseiro.com/#me)
+* elf Pavlik
+* Laurens Debackere
+* [Jackson Morgan](https://jackson.solidcommunity.net/profile/card#me)
+* April Daly
+* [Matthias Evering](https://solidweb.me/testpro/)
+* Oz Olivo
+* Tim Berners-Lee
+* [Ted Thibodeau](https://github.com/TallTed/) (he/him) (OpenLinkSw.com)
+
+---
+
+## 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/solid/specification/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 Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
+* 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
+* April Daly
+
+### Introductions
+* name: text
+
+---
+
+
+## Topics
+
+### Affiliations
+* SC: I'd like to announce a change in my affiliation and contribution agreement to the CG. I have agreed to participate as an individual under the W3C CLA.
+* SC: All, please make sure that your contribution agreement is up to date.
+* SC: Shall participate as an individual contributor, i.e., no affiliation. Everything else remains as it is.
+* 
+
+### Implementation Feedback
+* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
+* SC: This topic has been discussed in the notifications panel. Any news about implementations is welcomed. Feel free to demo or make announcements regarding any implementations that you would like to share.
+* EP: Currently working on a project that can be demonstrated in a couple of weeks. Please contact regarding any use cases that you would like to see demonstrated. I work on it under a project with NLnet. Current task focuses on flow where the app redirects the user to an authorization agent initiating sharing of some resource(s) selected inside the app.
+* LD: Hope to be able to give a demonstration in the month of April.
+
+
+### Add TR/2022/notifications-protocol-20221231
+URL: https://github.com/solid/specification/pull/491
+
+* SC: Feedback? Questions? Objections?
+* eP: Process question: what's blocking to merge?
+* SC: Deep topic — scope? Appropriate to have: 1) other solid editors to "BE" solid editors and engage in the community group, 2) recommendations (informal) by community groups to propose a merge date (if not objections by that date)
+* eP: We need to timebox the period for raising objections/comments. Also explicitly request reviews from editors expected to provide their review.
+* SC: There are other reasons to be considered but they are beyond the scope and time of this meeting.
+* SC: Milestones for both notifications and Solid protocol. For notifications, a number of items were not placed in V0.2, but will be in the next version, now under development.
+
+### Add TR/2022/protocol-20221231
+URL: https://github.com/solid/specification/pull/492
+
+* SC: Feedback? Questions? Objections?
+
+
+### Solid Protocol Version 0.11.0
+URL: https://github.com/solid/specification/milestone/7
+
+* SC: Tentative due date: 2023-04-30.
+* SC: Earlier we discussed Solid protocol for version 0.10.0. [Milestone 7](https://github.com/solid/specification/milestone/7) is the next set of works to be captured. There are a number of items on course for version 0.11.0, but we wanted to get feedback from the group before moving forward. If you want to propose an issue or milestone — please do (please keep it within the scope and format). 
+* SC: Unless there are preferences for topics and order, suggestion is to use the current order.
+
+
+### Shapes Reuse
+* SC: "Shapes" pertain to SHACL or ShEX.
+* SC: Should we have a shared space where shapes are developed and reused? Here are some existing work and considerations:
+  * Specifications include data modeling, e.g., <https://solid.github.io/notifications/protocol#data-model>, <https://solidproject.org/TR/wac#authorization-rule>.
+  * Specifications describe Constraints and Problem Details, e.g., <https://solidproject.org/ED/protocol#constraints-problem-details>.
+  * Resource servers can process write operations with shape validation.
+  * Applications can be informed on shapes and constraints on resources, e.g., <https://shapetrees.org/TR/specification/>.
+  * Create <https://github.com/solid/shapes>? There are services like <https://shaperepo.com/> that we can consider to reuse or have something similar that works through Solid org and/or CG?
+  * Also considerations for the WebID protocol and similar protocols for shapes/specs relative to this area. There is a question on where to put them. There is a shape resource service where you can put in shapes.
+* eP: Interop specs — data models also have shapes, shape trees. Recently adjusted shapetrees for discovery of predicates that can be used in general purpose apps to show human readable labels.
+* TBL: The shape repo only has shapes (doesn't have the specs). Have to develop shapes as part of your specs. Good practice to have shapes built into the specs. We should have a repository for client-to-client specs. The size is quite small. If end up with more than one repo, it will be unmanageable. Why not have an inner repo? Suggestion: a core repo for client specs. Things like contacts, profile, chat. There have been multiple implementations of Solid chat — it is being tweaked.
+* JM: Haven't updated shape repo. Can update the current repo based on feedback.
+* SC: How do we want to use them? GitHub makes sense for the one repo that has shapes, but what about reuse? Can servers reuse URLs? can all the requests be subject to validation based on the rules defined?
+* eP: We also need to be careful about different purposes and what is being curated/merged. They can be either SHACL or ShEX. it would good to have some guidelines about what can be assumed, etc.
+* SC: Let's create an issue with a few features that we want (i.e., not a big project, but focused on what we want).
+* TBL: Keeping other copies is important. Shape is part of the spec, so it is reasonable ... they should have a canonical URL. A URL for the canonical version, a URL for the current version. Could be an issue with keeping synchronization (e.g., with multiple copies). The canonical version, the source version...
+* SC: question: can we approach it the way we handle vocabularies?
+* TBL: Yes, we can use the same workflow as with vocabs. Also, W3C namespace could host shapes as it does with vocabs.
+* LD: In our apps, we have been mostly using SHACL, due to our toolchain. Toolchain starts from a UML model based on a domain and it generates shapes from those inputs. Versioning has been an important challenge. URIs have also been a challenge regarding whether they are consistent.
+* SC: Seems some agreement on having a "Shapes" repo.
+* TBL: Shapes may be too general. Suggest having a core shapes repo for Solid ecosystem. Not a repo for shapes; the shapes are part of the spec. Ontology and shapes are typically machine-readable parts of the spec.
+* SC: There are shapes in all models/specs.
+* TBL: Anything the server knows about is in the Solid protocol. Working group will extend the work (once formed) .
+* SC: Many servers will likely need the same shapes. Best if they are not creating their own shapes and instead using shapes defined by SOLID.
+* TBL: Like error responses?
+* SC: Yes.
+* TBL: There might be other shapes the server needs to know about (e.g., validation errors, server logs files, etc.). In the CG, we have been discussing the client specs and looking ahead to items that the WG will take up.
+* SC: Working groups operate for a fixed period (i.e., deadline driven). For the long term, the work will be managed by the broader community (CG/WG). 
+* TBL: CSS work is ongoing (i.e., never finished).
+* SC: Hope Solid will be as successful as CSS or HTML.
+* VB (on Jitsi chat): I think it might be worth picking up the Shapes topic in an issue. I can open one. As I think we might be talking about slightly different things. 
+
+
+
+### AuthN and AuthZ Server side clients (apps)
+URL: https://github.com/solid/specification/issues/504
+
+* SC: Topic proposed by eP.
+* SC: [Previous discussion](https://github.com/solid/specification/blob/main/meetings/2023-02-15.md#coordinating-further-work-on-authentication-and-authorization) 
+* JM: would like to write the spec over the next few weeks. If anyone has  suggestions for the draft specification, please detail in an issue.
+* SC: We can create a separate repo for what you would like to propose and treat it as a work item. If it has sufficient maturity, we can introduce it to Solid as a PR. 
+* JM: Create a new repo?
+* SC: Not completely clear on the scope. Want to avoid overlap. Can you provide some more detail?
+* JM: eP described the issue well in [Issue 504](https://github.com/solid/specification/issues/504)
+* eP: I did link to the prior work for authentication flows (first link). Suggest create a private repo allowing contributors and then move it to the desired repo when appropriate.
+* LD: We have created some stop-gap measures. Too big to discuss in this meeting. 
+* SC: what would be the name? Authentication flow? what a name that is meaningful.
+* JM: Self-sovereign method (using self-sovereign keys). Not sure if appropriate.
+* TBL: It's the people! 
+* eP: there are a few examples. Notification Server and Authorization agent