# W3C Solid Community Group: Weekly

* Date: 2024-01-17T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification

## Present
* [Michiel de Jong](https://michielbdejong.com) (chair)
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* Maxime Lecoq
* Hadrian Zbarcea
* [Sarven Capadisli](https://csarven.ca/#i)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* Reza Soltani
* [April Daly](https://aprildaly.me)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* michal/mrkvon
* Fred Gibson

---

## 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 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
* Sarven Capadisli
* Virginia Balseiro

### Introductions
* name: text

---

## Topics

### Open spec PRs

#### Add security consideration for serving user-created files
URL: https://github.com/solid/specification/pull/598

* VB: Please review.
* SC: Tied to an issue, some discussion in the PR.Wrote a comment earlier. Thought this through for a while. I think the consideration is good and we should have more stuff along those lines. Depending on whether the protocol expresses a need like that says something else about the architecture. There's some assumptions baked into this. It has some tradeoffs/conflicts with other things. We should weigh a bit more and discuss further before assuming it is as intended. Does this belong in that general pattern? Is it consistent with the rest of the design? Just my considerations.
* MdJ: Makes sense.
* eP: We should add it as soon as possible in whatever form we reach rough consensus. Still at least list the possible issue. We can't expect everyone to be aware of the issues. It could be an inline issue to make people aware possible exists. And perhaps people give valuable feedback.
* RG: Do we have like kanban board
* SC: We have a project board: https://github.com/orgs/solid/projects/15/views/3
* MdJ: We don't have a team of people working on it.
* MdJ: Please comment on the issue.

### Access to Chairs on the Repo
* eP: Do all chairs have access to solid/specification?
* VB: I can take care of it.

ACTION: VB to give access to co-chairs to solid/specification

### Project board
* RG: Should the project board be linked from ???
* SC: Stuff that has been mostly active until last release been updating in some ways more towards milestoning for next release. Doesn't have categorization of more recent issues. That can be improved. Process those last issues into this board. They're not there.
* MdJ: If Sarven is not regularly grooming, then it's not good to link. Unless RG you want to pick it up yourself.
* SC: Virginia will take care access to chairs and can say more on project board e.g. STM.
* VB: How are they related? Right for STM, not for issues. If that can be useful we can add more recent issues or talk about in these meetings.
* MdJ: We shouldn't link to it until someone works on it.
* HZ: I can help if we agree there is value.
* VB: I can look into using the board as mentioned.
* HZ: If we agree it has value I can groom it.
* MdJ: I don't see particular value in it. There's more value if people want to do more work on the spec to do more PR reviewing, higher priority.
* HZ: Agree but quite a few open issues.
* VB: Agree with MDJ. Focus on PR review, and if time/resources are available.
* MdJ: Can use these meetings as "our board".
* eP: I'd support it. I can join HZ on this for next week discussion.
* HZ: Sounds good.
* RG: This is so that anybody who comes to this can have a centralised view which might make it easier.
* MdJ: I'd be careful to not pick up work that we might not need. I'd say we try to work on the PRs and feel that not enough clarity and other issues to work, we can dig them up.

#### Clarify requests with N3 document in server-representation-turtle-jsonld
URL: https://github.com/solid/specification/pull/608

* MdJ: This clarifies that when there is an N3 document, it should the same as RDF document. I suggested for the purposes of N3 patch
* eP: I want to clarify the intent of this. In LDP we talk about (Non)RDF-Sources. Here we try to avoid that distinction but here we do. With N3 it happens to use an N3 document. The way to formulate may be to consider whether SPARQL Update may be used in the future. Take some time and see if we can formulate it in a way that's special for N3 but can also work with SPARQL. Also consideration on what's mature that can go to spec.
* MdJ: Want to make a suggestion into the spec of that wording?
* eP: What do we think about instead of going through content types, like RDF and non-RDF sources. Then we don't have to list all patches.
* SC: I asked for clarification in the chat. Some of that still applies. The requirement is more of a category of formats. The way it's written is not tied to a particular patch format. The only thing the spec says is patch is done this way, completely orthogonal to the formats that a server may be accepting, and if it does it needs to make available in ??? Right now the spec implies a server should be able to take an N3 document when you make a patch. Right now we're only saying RDF document but that is not entirely true. IF we want to say SPARQL is needed, that can be captured along those lines. There is nothing more generic to capture... right now we capture those two.
* MdJ: What about ??? not say anything about the body but the target.
* SC: Creating.
* eP: in the context of creating. If you use SPARLQ Update patch to create an RDF resource, ???
* MdJ: Continue in PR?
* eP: It should covers
* SC: What notion do you know that would cover RDF, N3, SPARQL..
* MdJ: Don;'t refer to body but target.
* SC: You're saying if I give you an image you can give that back in turtle.
* MdJ: Let's continue on PR.

#### Add document status to guides, templates
URL: https://github.com/solid/specification/pull/613

Proposed by: SC

* MdJ: You're marking some documents as no longer in effect..
* SC: We're using w3c solid cg repo and that's the source of truth. Minor.
* VB: Approved.

#### Should Solid (storage) servers support "RDF documents" containing multiple subjects (or quads)?
URL: https://github.com/solid/specification/issues/610

Proposed by: Maxime

* MdJ: This is more a question than a PR maybe?
* ML: Some implementation servers are not allowing multiple subjects in the payload when creating or updating resources. So, can't in some apps to apply the TypeIndex or any self-describing document. Was wondering it should not be part of the spec if / when we are accepting RDF document / graph we must accept the graph contains multiple subjects.
* MdJ: The spec allows the server. So can never be sure. If a server only accepts triples about the document, I'd say that server is broken.
* eP: Besides self-describing docs, certain predicates are used in a certain direction, like JSON-LD reverse. This is common in RDF. Since it is a graph, often things can be subject or object. I think it'd be interetsing to add a test case. What level would this requirement would be.
* MdJ: Even if you do WAC for instance, you'd have different Authorization rules. A test would fail in that case. That server wouldn't be compliant.
* PAC: Not sure I agree w/ you re any server should accept any type of content. I don't hav ea strong opinion. But can understand some people might want to develop servers maybe not generalist servers but still using some of the Solid server specification. Maybe it is not a good idea to rule out those people. I can share some things from the LDP work. I realised that some terms used in the group didn't make it to the spec. Used to talk about vanilla and chocolate servers - generalist servers and passive servers vs. the ones to put arbitrary resources.
* eP: Should get back to this topic when server validation. If server advertises a shape, and not just arbitrary. I agree not every server can but can advertise the added payload.
* MdJ: That'd be perhaps in future spec?
* SC: Current spec says.. category of contraints, one imposed by the server, expectation that container should behave.. Anything beyond is open, spec allows the case PAC was mentioning. There's also the possibility to advertise those contraints. Existing servers, if they want to continue doing what they're doing might want to get into that habit.
* SC: There's a similar consideration raised in Solid Protocol, whether a read-only Solid server should be conforming. Normally we think read-write. Wehther a conforming server not implementing those methods.. Some servers might want to do the mminimal thing. That's fine.
* MdJ: "Advertising its chocolateness" (TM).
* ML: So this constraint would be know at run-time and not when they're choosing their pod. So then I get a pod but not might as expected.
* eP: Separate topic perhaps how people can choose. Who is setting the constraints. It wouldn't be arbitrary constraints. How we can educate users to picking a storage.
* SC: Server could pass the test suite. When it's deployed it could completely reject requests including multiple subject. I don't think test suite will catch that. Comes down to whether URI owner allows that.

### Demo
#### Solid Data Modules Intro
URL: https://github.com/solid-contrib/data-modules

Proposed & presented by: Michiel

* MdJ: Slides: https://github.com/michielbdejong/presentations/blob/main/sdm-cg-17-jan.pdf
* MdJ: Solid Data Modules uses the platform for data interopearbility. I'd call "'small' Solid = RWW". As a power user there can be data browsers. mashlib is one. Also from modula, ontolo. Kind of like SolidOS where any data has a particular shape can have a view. I also see a bigger vision "'big' Solid = data pivot". It is a datastore. The GUI running on top of it. We need a much stricter spec for pod as a data pirvot. App A writes to Solid Pod and read by App B. For one power user, usefullness comes if it can be reused by App B. For that to open apps need to know what to expect from the pod, when it will fail, or discoverably capabilities for minimal reliable working thing. Data application rights need to be available in an understandable way. but then the choice of ontology and data shape matters. The business logic around that need sto be understood. need server behaviour to be strict - can't have chocolate servers - have data conventions, which ontologies to use - even if we care a WebID Profile it owuld have x:name but the app is using y:name. No good data conventions and also access control and they go hand in hand. The activities in Data Modules, we document and write translations between formats, reusable code in JavaScript, which handles the translation for you. This is one of the sites where we document data conventions. For example, bookmarking is in different vocabs. It'd be nice to make that compatible. Some apps use x and other y without knowing the other exists. SDM also abstracts them.
* MdJ: There is a chat room, NLnet funding for this project.
* eP: Looks interestsing and with demos would be good in action. For different apps or templates from servers, they don't have a strong reason to use this or some kind of a best practice. Devs go to NPM and tend to pick things wiht most downloads. Most of us take our extensions to use what they'll use. Most devs would be happy to choose the simpler.
* eP: As soon as we have something like recommended shape. Similar like schemaorg - tightly curated schema - and there is LOV to pick from.
* MdJ: We don't have the issue tracker to ???
* eP: You mentioned data types for access control. For SAI we have access needs to reference a project as an IRI.
* MdJ: I'd want to import difference ones from my pod and use code that can read both formats.

--- end of meeting ---
--- not discussed: ---

### General Discussion
#### Work Item Proposal: Solid Application Requirements
URL: https://github.com/solid/specification/issues/615

#### CG Call Frequency
* MdJ: We could consider having fewer and lighter plenary CG calls, in favour of more in-depth work meetings on specific work items, and moving spec PR reviews into either async for small ones or STMs for bigger ones (then also requiring the STM to write its conclusions into the issue it was about).

PROPOSAL: text
* name: +1,0,-1

RESOLUTION: text

ACTION: text