solid · elf-pavlik · Apr 8, 2026 · TallTed · Apr 10, 2026 · TallTed
diff --git a/meetings/2026-64-08.md b/meetings/2026-64-08.md
@@ -0,0 +1,176 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2026-04-08T14:00:00Z
+* Call: https://meet.jit.si/solid-cg
+* Repository: https://github.com/solid/specification
+
+## Chair
+
+* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+
+## Present
+
+* Alain Bourgeois
+* Roberto S.K. Breitman
+* Samu Lang
+* [Luke Dary](https://w3c.social/@lukedary)
+* [Rui Zhao](https://me.ryey.icu)
+* Tanya Gray
+* Precious Oritsedere
+* [Ted Thibodeau Jr](https://www.linkedin.com/in/macted/) (he/him) (OpenLinkSw.com) // GitHub:[@TallTed](https://github.com/TallTed) // Mastodon:[@TallTed](https://mastodon.social/@TallTed)
+
+
+## Regrets
+
+* Christoph
+* Theo
+
+---
+
+## Scribe
+
+* one per topic
+
+### 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
+
+
+## Announcements
+
+### Open Source Tools
+https://www.w3.org/events/meetings/74270982-945d-4b0d-b344-e7aa76383d83/20260408T150000/
+
+* eP: Next meeting right after this CG meeting!
+* eP: Would anyone like to co-lead it with Jackson?
+
+
+## Topics
+
+
+### Action review
+
+* ✅ Sarven PRs WAC / ACP data https://github.com/w3c-cg/solid/pull/78
+
+### Demos
+
+* eP: Since we aren't seeing any new demos, can we assume that there isn't any implementation work happening?
+* eP: Who would like to do short demos in upcoming weeks? I can do another short one of sai-js eg. access grants.
-* eP: Who would like to do short demos in upcoming weeks? I can do another short one of sai-js eg. access grants.
+* eP: Who would like to do short demos in upcoming weeks? I can do another short one of `sai-js`, e.g., access grants.
-* eP: Who would like to do short demos in upcoming weeks? I can do another short one of sai-js eg. access grants.
+* eP: Who would like to do short demos in upcoming weeks? I can do another short one of `sai-js`, e.g., access grants.
+
+### Presentation of ODI Persona Groups Operating Model (Roberto Breitman to present)
+
+![image](https://hackmd.io/_uploads/S13JM1N2bl.png)
+
+Context: For Solid26, ODI organises groups representing ?. Asking for feedback about Solid for them, for what would help adoption.
+
+* Roberto: presents, welcomes feedback.
+* ...: Reflects what was done for CDMC by Oli Bage.
+* ...: Project is part of ODI Stewardship of Solid.
+* ...: Leadership is board and advisory committee.
+* ...: PM by ODI leadership team.
+* ...: As well as Feedback Panel.
+* ...: Explain structure of WGs.
+* ...: Champion is expert of implementation in WG area. Can put lots of time in. Can attract peers for feedback. Strive for diversity of practitioners.
+* ...: Some WGs already settled e.g. EDMA who are willing to invest time into Solid.
+* ...: E.g. Gov leads: Will look across different governments (multinationally) for diversity of use cases across the world.
-* ...: Some WGs already settled e.g. EDMA who are willing to invest time into Solid.
-* ...: E.g. Gov leads: Will look across different governments (multinationally) for diversity of use cases across the world.
+* ...: Some WGs already settled, e.g., EDMA, who are willing to invest time into Solid.
+* ...: E.g., Gov leads: Will look across different governments (multinationally) for diversity of use cases across the world.
-* ...: Some WGs already settled e.g. EDMA who are willing to invest time into Solid.
-* ...: E.g. Gov leads: Will look across different governments (multinationally) for diversity of use cases across the world.
+* ...: Some WGs already settled, e.g., EDMA, who are willing to invest time into Solid.
+* ...: E.g., Gov leads: Will look across different governments (multinationally) for diversity of use cases across the world.
+* ...: Will ask WGs for output as spreadsheet of priorities. Then Feedback Panel will prioritise across WGs.
+* ...: Panel comprised of persona group leads. Also members from adisory committee. Also W3C rep who know global context and are well placed to communicate outcomes widely.
-* ...: Panel comprised of persona group leads. Also members from adisory committee. Also W3C rep who know global context and are well placed to communicate outcomes widely.
+* ...: Panel comprised of persona group leads. Also members from advisory committee. Also W3C rep(s) who know global context and are well placed to communicate outcomes widely.
-* ...: Panel comprised of persona group leads. Also members from adisory committee. Also W3C rep who know global context and are well placed to communicate outcomes widely.
+* ...: Panel comprised of persona group leads. Also members from advisory committee. Also W3C rep(s) who know global context and are well placed to communicate outcomes widely.
+* ...: Living doc to be launched at symposium.
+*
+Q: Michal: Add Practitioners to Implementers section?
+A: They would do it via CG and other existing mechanisms.
+Q: Implementers have a lot to say about changing Solid. They might belong in these groups.
+A: Practicioners are good source of feedback. One of many. They are individual implementers.
+
+Q: Pavlik: Had a group for social good? (Differs from enterprise etc).
+Q: Michal: What is the diff between app implementer and spec implementer?
+A: One person can participate in multiple groups. Wear hats based on skill. We should finalise details with practicioners themselves.
+
+https://github.com/solid-contrib/practitioners/blob/main/advisory-committee-presentations/solid-ecosystem-2.drawio.png
+
+Q: Tanya: Based on above diagram link
+A: Need time to consider diagram. Details of WGs will come later and will consider.
+Q: Michal: Concerned about mixing terms (practitioner)
+A: This is an activity within 'practitioners'.
+https://github.com/solid/specification/discussions/632
+A: Pavlik: Above shows existing feedback loops.
+
+### [New Work Item]: Solid26 Implementors Guide
+https://github.com/solid/specification/issues/773
+https://github.com/solid/specification/pull/776
+
+* eP: What are the plans for https://github.com/solid/solid26
+* eP: How many new documents Solid 26 will be composed of?
+* JW: N3
+* JW: Inclusion of other documents
+
+* JW: thank sarvin for feedback, and that CB is working with him on this, though he is unable to join today. 
-* JW: thank sarvin for feedback, and that CB is working with him on this, though he is unable to join today. 
+* JW: thank Sarven for feedback, and that CB is working with him on this, though he is unable to join today. 
-* JW: thank sarvin for feedback, and that CB is working with him on this, though he is unable to join today. 
+* JW: thank Sarven for feedback, and that CB is working with him on this, though he is unable to join today. 
+* JW: shares screen to go over the pull request (listed above) - At present we have an abstract talking about what Solid26 is: Nonormative document, a collection of exsiting works. Key thing being servers should comply to WAC, may also support ACP (as per the survey conducted last week), it points to a snapshot of WAC which may be updated if Sarven puts up a new version before Solid26. Also includes work on guidance by Samu
-* JW: shares screen to go over the pull request (listed above) - At present we have an abstract talking about what Solid26 is: Nonormative document, a collection of exsiting works. Key thing being servers should comply to WAC, may also support ACP (as per the survey conducted last week), it points to a snapshot of WAC which may be updated if Sarven puts up a new version before Solid26. Also includes work on guidance by Samu
+* JW: shares screen to go over the pull request (listed above) - At present we have an abstract talking about what Solid26 is: Non-normative document, a collection of existing works. Key thing being servers should comply to WAC, may also support ACP (as per the survey conducted last week), it points to a snapshot of WAC which may be updated if Sarven puts up a new version before Solid26. Also includes work on guidance by Samu.
-* JW: shares screen to go over the pull request (listed above) - At present we have an abstract talking about what Solid26 is: Nonormative document, a collection of exsiting works. Key thing being servers should comply to WAC, may also support ACP (as per the survey conducted last week), it points to a snapshot of WAC which may be updated if Sarven puts up a new version before Solid26. Also includes work on guidance by Samu
+* JW: shares screen to go over the pull request (listed above) - At present we have an abstract talking about what Solid26 is: Non-normative document, a collection of existing works. Key thing being servers should comply to WAC, may also support ACP (as per the survey conducted last week), it points to a snapshot of WAC which may be updated if Sarven puts up a new version before Solid26. Also includes work on guidance by Samu.
+* SL: the suammry is: these are the things he knows an implementos would need to knwo to work WebID - everything thatc omes to mind when thinking about building with WebID in the Solid ecosystem.
-* SL: the suammry is: these are the things he knows an implementos would need to knwo to work WebID - everything thatc omes to mind when thinking about building with WebID in the Solid ecosystem.
+* SL: the summary is: these are the things he knows an implementor would need to know to work WebID — everything that comes to mind when thinking about building with WebID in the Solid ecosystem.
-* SL: the suammry is: these are the things he knows an implementos would need to knwo to work WebID - everything thatc omes to mind when thinking about building with WebID in the Solid ecosystem.
+* SL: the summary is: these are the things he knows an implementor would need to know to work WebID — everything that comes to mind when thinking about building with WebID in the Solid ecosystem.
+* EP: how do you see the dif between the webid profile draft, and this?
+* SL: i dont think i can summarize this simply, in this doc Samu has tried to skip over things seen as being contentious, and focus on things we agree are useful.
-* SL: i dont think i can summarize this simply, in this doc Samu has tried to skip over things seen as being contentious, and focus on things we agree are useful.
+* SL: i don't think i can summarize this simply. in this doc, Samu has tried to skip over things seen as being contentious, and focus on things we agree are useful.
-* SL: i dont think i can summarize this simply, in this doc Samu has tried to skip over things seen as being contentious, and focus on things we agree are useful.
+* SL: i don't think i can summarize this simply. in this doc, Samu has tried to skip over things seen as being contentious, and focus on things we agree are useful.
+* AB: I notice you indicate a need to use M3Patch, but is that required to all servers 
-* AB: I notice you indicate a need to use M3Patch, but is that required to all servers 
+* AB: I notice you indicate a need to use M3Patch, but is that required of all servers?
-* AB: I notice you indicate a need to use M3Patch, but is that required to all servers 
+* AB: I notice you indicate a need to use M3Patch, but is that required of all servers?
+* JW: as it sitands it is not required in servers, meaning clients should not expect to see it. Sarven asked why we left it out, my answer (connected on a conversation with TimBL) is that not all servers implement M3Patch - i sudgested we try and do a similar data gathering exercise to what we did with Wac/ACP, and im inclined to hold that qiuestion to later in the week so we can roll it in with more questions we would ahve for server implemntors. 
-* JW: as it sitands it is not required in servers, meaning clients should not expect to see it. Sarven asked why we left it out, my answer (connected on a conversation with TimBL) is that not all servers implement M3Patch - i sudgested we try and do a similar data gathering exercise to what we did with Wac/ACP, and im inclined to hold that qiuestion to later in the week so we can roll it in with more questions we would ahve for server implemntors. 
+* JW: as it stands, it is not required in servers, meaning clients should not expect to see it. Sarven asked why we left it out. My answer (connected to a conversation with TimBL) is that not all servers implement M3Patch — I suggested we try and do a similar data gathering exercise as what we did with WAC/ACP, and I'm inclined to hold that question to later in the week, so we can roll it in with more questions we would have for server implementors. 
-* JW: as it sitands it is not required in servers, meaning clients should not expect to see it. Sarven asked why we left it out, my answer (connected on a conversation with TimBL) is that not all servers implement M3Patch - i sudgested we try and do a similar data gathering exercise to what we did with Wac/ACP, and im inclined to hold that qiuestion to later in the week so we can roll it in with more questions we would ahve for server implemntors. 
+* JW: as it stands, it is not required in servers, meaning clients should not expect to see it. Sarven asked why we left it out. My answer (connected to a conversation with TimBL) is that not all servers implement M3Patch — I suggested we try and do a similar data gathering exercise as what we did with WAC/ACP, and I'm inclined to hold that question to later in the week, so we can roll it in with more questions we would have for server implementors. 
+* AB: yes but there were other methods to use, most servers are using Sparkle updates 
+* JW: yes, though sparkle updates are not in the current specs - so in the current guide there is not patch recomendation.
+* EP: ill take the opportunity to put Erich on the spot and ask how patching is done in LWF
-* AB: yes but there were other methods to use, most servers are using Sparkle updates 
-* JW: yes, though sparkle updates are not in the current specs - so in the current guide there is not patch recomendation.
-* EP: ill take the opportunity to put Erich on the spot and ask how patching is done in LWF
+* AB: Yes, but there were other methods to use. Most servers are using SPARQL Update.
+* JW: Yes, though SPARQL Update is not in the current specs — so in the current guide, there is no patch recommendation.
+* EP: I'll take the opportunity to put Erich on the spot, and ask how patching is done in LWS.
-* AB: yes but there were other methods to use, most servers are using Sparkle updates 
-* JW: yes, though sparkle updates are not in the current specs - so in the current guide there is not patch recomendation.
-* EP: ill take the opportunity to put Erich on the spot and ask how patching is done in LWF
+* AB: Yes, but there were other methods to use. Most servers are using SPARQL Update.
+* JW: Yes, though SPARQL Update is not in the current specs — so in the current guide, there is no patch recommendation.
+* EP: I'll take the opportunity to put Erich on the spot, and ask how patching is done in LWS.
+* EB: its defined in JSON (from EB in chat: and by PATCH for json, I mean specifically, JSON Merge Patch RFC7386 )
+* EP: i woul;d sudgets we dont try to get patch right in this pull request, we can adress that later int he week (tackle these things one at a time)
+* JW: i think the discussion to have in this group is the genral design priocipal of this implemntors guide: so far the idea has been to be very minimal, my sudgestion is that for Solid26 we let people see little at first and discover the rest of the specs as they go on. Meaning anything that are not extremely stable across servers and clients in the Solid ecosystem we leave out of this document.
-* EB: its defined in JSON (from EB in chat: and by PATCH for json, I mean specifically, JSON Merge Patch RFC7386 )
-* EP: i woul;d sudgets we dont try to get patch right in this pull request, we can adress that later int he week (tackle these things one at a time)
-* JW: i think the discussion to have in this group is the genral design priocipal of this implemntors guide: so far the idea has been to be very minimal, my sudgestion is that for Solid26 we let people see little at first and discover the rest of the specs as they go on. Meaning anything that are not extremely stable across servers and clients in the Solid ecosystem we leave out of this document.
+* EB: It's defined in JSON _(from EB in chat: and by PATCH for JSON, I mean specifically, JSON Merge Patch RFC7386)_
+* EP: I would suggest we don't try to get patch right in this pull request. We can address that later in the week. (Tackle these things one at a time.)
+* JW: I think the discussion to have in this group is the general design principal of this implementor's guide. So far, the idea has been to be very minimal; my suggestion is that, for Solid26, we let people see little at first and discover the rest of the specs as they go on. Meaning anything that is not extremely stable across servers and clients in the Solid ecosystem, we leave out of this document.
-* EB: its defined in JSON (from EB in chat: and by PATCH for json, I mean specifically, JSON Merge Patch RFC7386 )
-* EP: i woul;d sudgets we dont try to get patch right in this pull request, we can adress that later int he week (tackle these things one at a time)
-* JW: i think the discussion to have in this group is the genral design priocipal of this implemntors guide: so far the idea has been to be very minimal, my sudgestion is that for Solid26 we let people see little at first and discover the rest of the specs as they go on. Meaning anything that are not extremely stable across servers and clients in the Solid ecosystem we leave out of this document.
+* EB: It's defined in JSON _(from EB in chat: and by PATCH for JSON, I mean specifically, JSON Merge Patch RFC7386)_
+* EP: I would suggest we don't try to get patch right in this pull request. We can address that later in the week. (Tackle these things one at a time.)
+* JW: I think the discussion to have in this group is the general design principal of this implementor's guide. So far, the idea has been to be very minimal; my suggestion is that, for Solid26, we let people see little at first and discover the rest of the specs as they go on. Meaning anything that is not extremely stable across servers and clients in the Solid ecosystem, we leave out of this document.
+
+Discussion with Michal - on put requests decvided to be taken in writing due to specificity.
-Discussion with Michal - on put requests decvided to be taken in writing due to specificity.
+Discussion with Michal — on put requests decided to be taken in writing due to specificity.
-Discussion with Michal - on put requests decvided to be taken in writing due to specificity.
+Discussion with Michal — on put requests decided to be taken in writing due to specificity.
+
+* EP: sudgests we get this pull request done soon so we have a basis to make pull requests on over the next few weeks. as we dont ahve much time to do all this in meetings. 
+* EP: what is the future of the Solid26 repo?
+* JW: I see this markdown doc as a very shorlived thing to help ppeople who are not in CG calls catch up on what Solid26 is - we are cuirrently working on full Solid26 webpages (Precious is on it). there will be 2 pages: one for fully leigh people, giving them info and inviting them to messege Roberto for rounting. the second is for impklentors worki g in Solid so new people coming in to the ecosystme know what we think about eh future of Solid (igrate to LWS). again this will be an opinionated docuemnt since we dont have consensus. 
-* EP: sudgests we get this pull request done soon so we have a basis to make pull requests on over the next few weeks. as we dont ahve much time to do all this in meetings. 
-* EP: what is the future of the Solid26 repo?
-* JW: I see this markdown doc as a very shorlived thing to help ppeople who are not in CG calls catch up on what Solid26 is - we are cuirrently working on full Solid26 webpages (Precious is on it). there will be 2 pages: one for fully leigh people, giving them info and inviting them to messege Roberto for rounting. the second is for impklentors worki g in Solid so new people coming in to the ecosystme know what we think about eh future of Solid (igrate to LWS). again this will be an opinionated docuemnt since we dont have consensus. 
+* EP: Suggest we get this pull request done soon so we have a base to make pull requests on over the next few weeks, as we don't have much time to do all this in meetings. 
+* EP: What is the future of the Solid26 repo?
+* JW: I see this markdown doc as a very short-lived thing, to help people who are not in CG calls catch up on what Solid26 is. We are currently working on full Solid26 webpages (Precious is on it). There will be 2 pages: one for fully lay-people, giving them info and inviting them to message Roberto for rounting(?). The second is for implentors working in Solid so new people coming in to the ecosystem know what we think about the future of Solid (migrate to LWS). Again, this will be an opinionated document since we don't have consensus. 
-* EP: sudgests we get this pull request done soon so we have a basis to make pull requests on over the next few weeks. as we dont ahve much time to do all this in meetings. 
-* EP: what is the future of the Solid26 repo?
-* JW: I see this markdown doc as a very shorlived thing to help ppeople who are not in CG calls catch up on what Solid26 is - we are cuirrently working on full Solid26 webpages (Precious is on it). there will be 2 pages: one for fully leigh people, giving them info and inviting them to messege Roberto for rounting. the second is for impklentors worki g in Solid so new people coming in to the ecosystme know what we think about eh future of Solid (igrate to LWS). again this will be an opinionated docuemnt since we dont have consensus. 
+* EP: Suggest we get this pull request done soon so we have a base to make pull requests on over the next few weeks, as we don't have much time to do all this in meetings. 
+* EP: What is the future of the Solid26 repo?
+* JW: I see this markdown doc as a very short-lived thing, to help people who are not in CG calls catch up on what Solid26 is. We are currently working on full Solid26 webpages (Precious is on it). There will be 2 pages: one for fully lay-people, giving them info and inviting them to message Roberto for rounting(?). The second is for implentors working in Solid so new people coming in to the ecosystem know what we think about the future of Solid (migrate to LWS). Again, this will be an opinionated document since we don't have consensus. 
+* EP: To me its importnat we connect Solid26 pages to what Roberto presented in terms of persona groups, and its important that Soli26 helps the CG build capacity (new people) to help improve Solid. 
+* JW: One thing im hoping the prioritising can help with is also finding the things that need the most work, and focus our energy limited as it is. 
-* EP: To me its importnat we connect Solid26 pages to what Roberto presented in terms of persona groups, and its important that Soli26 helps the CG build capacity (new people) to help improve Solid. 
-* JW: One thing im hoping the prioritising can help with is also finding the things that need the most work, and focus our energy limited as it is. 
+* EP: To me, it's important that we connect Solid26 pages to what Roberto presented in terms of persona groups, and it's important that Solid26 helps the CG build capacity (new people) to help improve Solid. 
+* JW: One thing im hoping the prioritising can also help with is finding the things that need the most work, and focusing our energy, limited as it is. 
-* EP: To me its importnat we connect Solid26 pages to what Roberto presented in terms of persona groups, and its important that Soli26 helps the CG build capacity (new people) to help improve Solid. 
-* JW: One thing im hoping the prioritising can help with is also finding the things that need the most work, and focus our energy limited as it is. 
+* EP: To me, it's important that we connect Solid26 pages to what Roberto presented in terms of persona groups, and it's important that Solid26 helps the CG build capacity (new people) to help improve Solid. 
+* JW: One thing im hoping the prioritising can also help with is finding the things that need the most work, and focusing our energy, limited as it is. 
+
+### WebID or WebID-Profile
+https://www.w3.org/2005/Incubator/webid/spec/identity/
+https://solid.github.io/webid-profile/
+https://github.com/solid/webid-profile/discussions/122
+
+
+### Solid Shapes
+ - https://github.com/solid/shapes
+
+* JW: Shapes repo content overview (tgra)
-* JW: Shapes repo content overview (tgra)
+* JW: Shapes repo content overview (https://github.com/tgra/)
-* JW: Shapes repo content overview (tgra)
+* JW: Shapes repo content overview (https://github.com/tgra/)
+* TG: The shape repo currently holds shapes extracted from SolidOS. The goal of the repository is to support interoperablity across semantic domains. In addition to the shapes that are there, there are guidelines for how people can contribute shapes.
+* JW: Goal is to enable interop within Solid ecosystem as it stands today. We don't have huge number of apps but hope this number can grow. In short term we can provide human consensus way to collect what apps are using. You capture the data model within this repo by creating a PR, this way people can see what others are using. When you build a new app you try to reuse the shape. It is an experiment, we don't know if people will adopt it, what is the right incentive. In email thread Virginia have asked what is the gov process. Proposal is that while it is small we get 10-15 shapes contributed and ODI governs it. Should it proved to be a success and CG wants to take ownership we can talk about it.
-* TG: The shape repo currently holds shapes extracted from SolidOS. The goal of the repository is to support interoperablity across semantic domains. In addition to the shapes that are there, there are guidelines for how people can contribute shapes.
-* JW: Goal is to enable interop within Solid ecosystem as it stands today. We don't have huge number of apps but hope this number can grow. In short term we can provide human consensus way to collect what apps are using. You capture the data model within this repo by creating a PR, this way people can see what others are using. When you build a new app you try to reuse the shape. It is an experiment, we don't know if people will adopt it, what is the right incentive. In email thread Virginia have asked what is the gov process. Proposal is that while it is small we get 10-15 shapes contributed and ODI governs it. Should it proved to be a success and CG wants to take ownership we can talk about it.
+* TG: The shape repo currently holds shapes extracted from SolidOS. The goal of the repository is to support interoperablity across semantic domains. In addition to the shapes that are there, there are guidelines for how people can contribute shapes.
+* JW: The goal is to enable interop within the Solid ecosystem as it stands today. We don't have a huge number of apps but hope this number can grow. In the short term, we can provide a human consensus way to collect what apps are using. You capture the data model within this repo by creating a PR; this way, people can see what others are using. When you build a new app, you try to reuse shapes. It is an experiment; we don't know if people will adopt it, nor what is the right incentive. In an email thread, Virginia has asked what is the governance process. Proposal is that while it is small, we get 10-15 shapes contributed, and ODI governs it. Should it prove to be a success and the CG wants to take ownership, we can talk about it.
-* TG: The shape repo currently holds shapes extracted from SolidOS. The goal of the repository is to support interoperablity across semantic domains. In addition to the shapes that are there, there are guidelines for how people can contribute shapes.
-* JW: Goal is to enable interop within Solid ecosystem as it stands today. We don't have huge number of apps but hope this number can grow. In short term we can provide human consensus way to collect what apps are using. You capture the data model within this repo by creating a PR, this way people can see what others are using. When you build a new app you try to reuse the shape. It is an experiment, we don't know if people will adopt it, what is the right incentive. In email thread Virginia have asked what is the gov process. Proposal is that while it is small we get 10-15 shapes contributed and ODI governs it. Should it proved to be a success and CG wants to take ownership we can talk about it.
+* TG: The shape repo currently holds shapes extracted from SolidOS. The goal of the repository is to support interoperablity across semantic domains. In addition to the shapes that are there, there are guidelines for how people can contribute shapes.
+* JW: The goal is to enable interop within the Solid ecosystem as it stands today. We don't have a huge number of apps but hope this number can grow. In the short term, we can provide a human consensus way to collect what apps are using. You capture the data model within this repo by creating a PR; this way, people can see what others are using. When you build a new app, you try to reuse shapes. It is an experiment; we don't know if people will adopt it, nor what is the right incentive. In an email thread, Virginia has asked what is the governance process. Proposal is that while it is small, we get 10-15 shapes contributed, and ODI governs it. Should it prove to be a success and the CG wants to take ownership, we can talk about it.
+* eP: I think it is important that job is getting done. CG had a plenty of oportunity to do it.
-* eP: I think it is important that job is getting done. CG had a plenty of oportunity to do it.
+* eP: I think it is important that this job is getting done. CG had a plenty of opportunity to do it.
-* eP: I think it is important that job is getting done. CG had a plenty of oportunity to do it.
+* eP: I think it is important that this job is getting done. CG had a plenty of opportunity to do it.
+* AB: I just made a PR for the long chat. It is different in ... pane but it has the same context. 
+* JW: Shape repo governance
+* JW: Moving content from https://github.com/solid-contrib/shapes back in
+* JW: (Experiment): Recommending locations of data storage https://github.com/tgra/solid-chat-location
+* TG: The requirement for chat channel to have new file each day conforming to certain pattern. This would require variables and how to represent it in SHACL. The use of templating came forward as an idea. I did some documentation, there's also idea of using Hydra templates. 
+* JW: There is a conversation a couple of steps back. It is another way of trying to help interop. The proposal is a way of defining within a shapes repo a fixed path within a storage. For example volunteering can be in `/volunteering/profiles`. For example the way chat spec requires a path today. 
-* TG: The requirement for chat channel to have new file each day conforming to certain pattern. This would require variables and how to represent it in SHACL. The use of templating came forward as an idea. I did some documentation, there's also idea of using Hydra templates. 
-* JW: There is a conversation a couple of steps back. It is another way of trying to help interop. The proposal is a way of defining within a shapes repo a fixed path within a storage. For example volunteering can be in `/volunteering/profiles`. For example the way chat spec requires a path today. 
+* TG: The requirement for a chat channel to have a new file each day conforming to a certain pattern. This would require variables and how to represent it in SHACL. The use of templating came forward as an idea. I did some documentation. There's also idea of using Hydra templates. 
+* JW: There is a conversation a couple of steps back. It is another way of trying to help interop. The proposal is a way of defining within a shapes repo a fixed path within a storage. For example, volunteering might be in `/volunteering/profiles`. For example, the way chat spec requires a path today.
-* TG: The requirement for chat channel to have new file each day conforming to certain pattern. This would require variables and how to represent it in SHACL. The use of templating came forward as an idea. I did some documentation, there's also idea of using Hydra templates. 
-* JW: There is a conversation a couple of steps back. It is another way of trying to help interop. The proposal is a way of defining within a shapes repo a fixed path within a storage. For example volunteering can be in `/volunteering/profiles`. For example the way chat spec requires a path today. 
+* TG: The requirement for a chat channel to have a new file each day conforming to a certain pattern. This would require variables and how to represent it in SHACL. The use of templating came forward as an idea. I did some documentation. There's also idea of using Hydra templates. 
+* JW: There is a conversation a couple of steps back. It is another way of trying to help interop. The proposal is a way of defining within a shapes repo a fixed path within a storage. For example, volunteering might be in `/volunteering/profiles`. For example, the way chat spec requires a path today.
+* JW: I steps on the toes of type indexes and SAI. We should discuss if this is an approach.
+* eP: ...
+* JW: For Soild26 we want to capture what people do in applications and reuse those shapes. Will there be a problem to ask people what paths they put their resources at?
+* eP: ...
+* JW: I think we should keep things easy. If we recommend something we should recommend.
+* eP: ...
+* eP: https://github.com/solid/contacts/issues/5
+*
+
+## Actions 
+* eP to schedule Luke's demo for next week
+* eP to schedule Rui's demo for 2 weeks from now
+
+## Decisions
+