# W3C Solid Community Group: Weekly

* Date: 2023-07-12T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* April Daly
* Laurens Debackere
* [TallTed](https://github.com/TallTed) // Ted Thibodeau (he/him) (OpenLinkSw.com)
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* Maxime Lecoq
* [Ross Horne](https://satoss.uni.lu/members/ross/)
* Hadrian Zbarcea
* Osmar Olivo
* Wouter Termont

---

## 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
* Virginia

### Introductions
* name: text

---

## Topics

### WIP Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.

### Update mission
URL: https://github.com/solid/solid-wg-charter/issues/7

* SC: This is editorial. PRs welcome.

### Inclusion of HTML in Solid
URL: https://github.com/solid/solid-wg-charter/issues/42

* SC: Asking to know where HTML fits into the Solid protocol and/or the Solid WG Charter as a delivery mechanism for Solid, and whther it should be in scope of the charter. I mentioned if it's a need we can raise in the Solid Protocol repo for ED. If it's for charter, it is likely to be out of scope, as there are other groups focused on HTML. This charter does not call out particular formats. Melvin suggested to look at 0.7 version of Solid specification and take that approach. I don't recall other than optionally using with RDFa, but there was no normative requirement.
* SC: Please share your thoughts/feedback on the issue. As it stands it is not particularly something needing to be in the WG Charter.
* LD: +1
* LD: It is perhaps a consideration for the Solid Protocol but not the Charter I think.

### Add W3C Solid CG Charter
URL: https://github.com/solid/process/pull/323

* SC: We're not looking to make a decision now. This is primarily to build awareness and gather feedback.
* SC: Re: the timeline: https://github.com/solid/process/pull/323#issuecomment-1629875377
* SC: If there's concern about dates we can cover now. Otherwise we stick to W3C process as a guideline.
* SC: Currently we have 6 reviews. And we have 5 approvals, 1 change request / objection. It does not indicate what the change is (inline). And a bunch of emoji reactions on the PR. Not quite insightful... We're working to figure out how we remove the objections through reaching some consensus.
* SC: I will try to sumarize what the charter is and where we are. The current Solid process we've been leaning on in the CG has been complicated and does not represent the reality of how CG is conducting its activities. From publciations, to having resources to take on responsibilities, to having editors team to do the essential parts. Lots of other things that aren't working. There's a lot of data to back this up. Please request any data that is missing or needas to be reviewed.
* RG: Which data are you talkign about?>
* SC: I made a claim that the current process ??? Editors team has been inactive. If you want the data to support that claim, please request it. You have to be familiar with the current solid process.
* RG: I am aware but there isn't a disagreement on this point. The disagreement is they do the other things that aren't going into the CG.
* SC: My point is the things that I said up to now and why this charter is needed, why this emerged, there is data for that and if you'd like to request I am happy to provide. If you're familiar with it, you're already aware of the issues. Just clarifying that there's grounds for the charter to exist.
* SC: We add scope, goals, communication with other groups, how to propose new work items (we need to move this to contributing guide). We also talk about Chairs, elections.
* SC: Please read and if you haven't, make suggestions, ask questions, request changes to make the text clearer.
* SC: We have some disagreement / objection. The group that participated mostly disagrees with the objection, but need to address. I will quote VB's comment:[ (quote / link to comment)](https://github.com/solid/process/pull/323#issuecomment-1632534129)
* SC: There's no doubt we want the output of the group to be useful to other groups. That said, the W3C CG is not the sole entity in the Solid project space. For example, it will not be taking on community reach of the WG. That means that if we say each group needs its own community outreach, we are saying this group can only contact about the particular work items of said group. That division is possible, maybe impractical. The understanding is someone needs to do it, one proposal is Solid Project at the root is where we try to coordinate that wide community outreach. The CG is doing a lot of it already. The objection is about making sure we take on other items that belong on the ??? of outreach. We just need to see through the discussion, have a further understanding with Solid Team as well. The definition as to what a CG entails, what a business group entails, what a WG entails are there. Some of the things that are requested from a CG here do not fall under a CG. We need to be better aware of it.
* LD: Thank you Sarven, it is a good starting point. I agree with JZ on some points. We need a clear vision as to how to incorporate stakeholders, and that needs to be somewhere. I do think there's an opportunity to clearly define who does what in terms of outreach on spec, implementors, gathering feedback and disaseminating why we make changes. That's not needed to be taken on by CG but we need to clarify where.
* WT: There are three different things: 1) should a CG try to gather relevant input to make the progresssion of spec possible? Yes. Can we do better? Possibly. The question is how. My proposal is to have a calls for feedback topic in the forum to retrieve more feedback. 2) should the CG try to communicate its output (spec changes) to broader community? Yes, it's part of its job. Can we do that better? Yes. But we need concrete proposal. Mine is we could when a PR is merge try to communicate that on relevant channels. 3) Should the CG be responsible for broader communication within the Solid project, broader than trying to get input and reaching the community with output, and there I agree with the majority that there exists a Team that does, and I think we can only try to support as much as we can.
* RG: What's happening I think is you're trying to replace the process with a CG charter. the process was broad and not just for Solid. CG is doing much more and those responsibilities need to be taken somewhere. That needs to be clarified.
* SC: We're on the ame page. CG charter is not throwing out all of the Solid process out. It is actually defining only what CG is doing that needs to be coordinated with Solid Project, just as WG, SolidOS... etc. are trying to coordinate under the Solid umbrella.
* RG: You're making claims that the process does not work.
* SC: In the context of how specs are developed.
* RG: Why don't you edit the process itself. Because otherwise it's creating confusion.
* SC: In that process as we speak.
* SC: Please review. This charter is for us.

### Clarify that slash doesn't entail containement
URL: https://github.com/solid/specification/pull/538

* eP: Added a [link to the issue](https://github.com/solid/specification/issues/505) which captures the problem well. Main thing to clarify is the slash semantics entailing that resource is contained. If there's a Solid storage and there's a slash we can conclude the resource is contained. Based on current implementations I created the PR to suggest why it's necessary to have slash semantics. Just because there's a certain structure in IRI does not entail it is contained, but based on comments I take it that implementations are incorrect. We need to clarify the assumptions to clarify what's needed to be added.
* eP: https://github.com/solid/specification/issues/505
* SC: There were a few suggestions. I'd like to know if we misunderstood your intentions or would you also find our suggestions suitable?
* eP: My clarification was it is necessary but not sufficient. Feedback suggests it's actually sufficient: just based on IRI one can infer something is contained. Which brings the topic of auxiliary resources. Based on that it can be inferred it is contained, but it's not, they are outside the containment. We need to clarify that and based on that look at the work.
* RG: Can you write down what kind of an example of an IRI for an auxiliary resource?
* eP: Here is an example: https://github.com/solid/specification/issues/505#issuecomment-1623697901
* TT: This tension is never going away. This is always going to be a conflict between the basic architecture of the web which decrees IRIs are opaque, you can't take meaning from an IRI. You cannot infer containment, location, anything from the string. It should be, to get this across cleanly, just jibberish. That's what the basic architecture of the web says. This building of a unix file system within a web architecture is an interesting idea but conflicts like this one is inherent in doing that.
* SC: There's a distinction between how IRIs are used in RDF and outside it. The hierarchical structure (slash) has a particular semantic. Originally Tim was thinking the mapping between slash and what we do in LDP, this containment idea.. and LDP mentions that slashes are a way of implementing ??? Solid's approach is a constraint.
* SC: Whether aux resources fit within this containment, it should be ??? somewhere it can be accessed but not navigated to independently. If we can improve the spec around that, be more clear about to what extent they're contained and whether the slash has any meaning. An aux resource could be in other server which is not necessarily a Solid server.
* RG: Can you clarify which particular document you refer to for LDP?
* SC: https://www.w3.org/TR/ldp-bp/
* WT: About [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986), I just want to clarify it does not fix the slash semantics to be in a hierarchy. It might have been a weakening of the writer's original version to have it be more flexible. I am not clear on what my opinion is. We should agree on that aux resources should not necessarily be contained resources.
* SC: The spec allows a variability, so it could be a contained resource, but the spec does not say how you would find that. You find a resource and look at the link relation and find it.
* SC: Could we narrow this issue to pose a question to the community as to whether we can discover aux resources independently.
* WT: Good idea to split it off. It seems weird that they should be contained.
* eP: I don't see a need for aux resources to be discoverable through other means than the main resource. It's fine to follow link relation. Up to the server. If current implementations are following the spec, should it also change it or do we want to allow that IRI for aux resource doesn't imply it's contained?
* SC: Suggestion in that PR was paraphrase to limit to in the context of what Solid means.
* WT: Maybe it's a good idea if people that know use cases for each of the sides can post them in the PR. What are specific cases which you can only do with one or the other.
* eP: I prefer to close the PR and continue on the issue.
* WT: +1.

PROPOSAL: Close PR and continue on issue.

No objections.

### Proposals for Dedicated Calls
* https://github.com/solid/specification/issues/525
* SC: There may have been other in recent discussions. But add here please to take into account for later.
* SC: I will propose some dates for the group. We should have 2 hours call to not rush.

### Add section describing the the relationship between Solid Protocol and LDP
URL: https://github.com/solid/specification/pull/539

* SC: It's been 9 days and we have 2 approvals. You're welcome to add comments. If you have objections, please raise. If not, we can merge.
* SC: Objections to merge?
* SC: No objections.

### Alternative solutions to container HATEOAS
URL: https://github.com/solid/specification/issues/525