-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Agenda for 2024-12-18 CG meeting (#702)
* Agenda for 2024-12-18 CG meeting Signed-off-by: Hadrian Zbarcea <[email protected]> * Updated minutes for 2024-12-18 CG meeting Signed-off-by: Hadrian Zbarcea <[email protected]> --------- Signed-off-by: Hadrian Zbarcea <[email protected]>
- Loading branch information
Showing
1 changed file
with
129 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,129 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-12-18T14:00:00Z | ||
| * Call: https://meet.jit.si/solid-cg | ||
| * Chat: https://matrix.to/#/#solid_specification:gitter.im | ||
| * Repository: https://github.com/solid/specification | ||
| * Status: Published | ||
|
|
||
| ## Present | ||
| * Hadrian Zbarcea | ||
| * Jesse Wright | ||
| * [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * Jeff Zucker | ||
| * [Pierre-Antoine Champin](https://champin.net/#pa) - 10' late | ||
| * [Erich Bremer](https://bmi.stonybrookmedicine.edu) | ||
| * [Rahul Gupta](https://cxres.pages.dev/profile#i) | ||
|
|
||
| --- | ||
|
|
||
| ## Announcements | ||
|
|
||
| * Solid Wallets [mini-hackathon series](https://www.inrupt.com/event/solid-hackathon/home) sponsored by Inrupt starts in January, running for 6 mo. Each mini-hackathon starts the second Monday of the month Jan-Jun. | ||
| * [FOSDEM](https://fosdem.org/2025/) Feb. 1-2 | ||
| * [State of open con](https://sessionize.com/state-of-open-con-2025/) - London conference on Open Source, Data and Hardware. Timed to be immediately after FOSDEM on Feb 4-5. | ||
|
|
||
| ### 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 | ||
| * elf Pavlik | ||
|
|
||
| ### Introductions | ||
| * none | ||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### Ownership of hackmd/@solid | ||
|
|
||
| * HZ: Should ownership be transfered back to eP? | ||
| ACTION: eP to reach out to Viriginia to transfer ownership | ||
|
|
||
| ### Special Topic Meetings | ||
|
|
||
| * eP: There is intrest to have one focused on ACL sytems like WAC and ACP. | ||
| * ... Following up on our agreement to remove the standing slot from the calendar, MdJ canceled it. | ||
| * ... I had the impression that Niko and Sebastien want to talk about WAC, so it would | ||
| * ... be a good idea to organize an STM. We need to find an expert in WAC, hopefully. | ||
| * ... MdJ wrote the tests, so he's definitely an expert. | ||
| * ... I'd like to check if MdJ would be interested, but he's not here. | ||
|
|
||
| ACTION: eP to check with MdJ | ||
|
|
||
| * eP: CRDT 4 RDF will have a CG meeting, their first one. https://lists.w3.org/Archives/Public/public-crdt4rdf/2024Dec/0004.html | ||
| * HZ: Niko came up with [a use case](https://github.com/w3c/lws-ucs/issues/24) in LWS use cases, about separating APIs from data formats. I see it as a collection of graphs. The way you store files you have something equivalent to [inodes](https://en.wikipedia.org/wiki/Inode). There are also the views that Ruben was talking about. You have a lot of interacting graphs in the storage. Then you have more volatile graph names possibly resulting from SPARQL queries. I would like to catalogue all the ideas that were discussed in Solid CG. Personally I would also distinguish between physical storage and logical storage, and an atomic unit of information that can be moved between providers while preserving addresses. | ||
| * JW: It is a can of worms. My expectation, having pushed on conceptualized hyper knowledge graph, for purposes of the LWS group, it should be largely about specifying existing filesystem APIs based on LDP. The logical storage that you are talking about is left out-of-scope for the WG. This could be discussed later. | ||
| * HZ: If you want to talk about portability of storage, you can't avoid it. | ||
| * JW: I don't think you will get portability in all cases. If you conform to file storage API, you would get it. Existing databases may not want to map to file storage. | ||
| * eP: By 'file storage', do you mean LDP-like system or filesystem? | ||
| * JW: I mean LDP-like, not the filesystem. | ||
|
|
||
| ### LWS Use Cases | ||
|
|
||
| * eP: Seeing a lot of activity, what is the plan for organizing all those UCs? | ||
| * eP: Should UCs refrain from suggesting specific possible solutions, or at least clearly separate the problem(s) from some possible solutions? | ||
| * HZ: Yes, UC should avoid solutions | ||
| * eP: 'User' related discussions | ||
| * HZ: This was already discussed on Monday at LWS meeting. I will create a glossary; there will be a PR. I expect conversations on the PR. I hope we can use consistent terminology. SC wants to be more disciplined with using terms. | ||
| * eP: Terms like "IRI templates" sound like a very specific approach, more likely a part of the solution than the problem. | ||
| * HZ: I would like to avoid prescribing solutions in the use cases. | ||
|
|
||
| ### Choosing a different term than C2C (continued) | ||
| URL: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$GTTvQgauz8PY6ky2bRSMwyFVxPceA47C52asMPYtDlY?via=gitter.im&via=matrix.org&via=chat.semantic.works | ||
|
|
||
| * eP: I think we were converging on 'data domain specs'. | ||
| * RG: Once Tim is back we will check with him those other terms. | ||
| * HZ: Line 103 in last meeting minutes. | ||
| * HZ: It seems that we generally agree that C2C is generally confusing. | ||
| * JW: I agree that C2C is not appropiate. There is an unresolved debate around how those specs should be defined. Should they be human readable, should they be defined with shapes and something like SAI. As a comunity, we should agree how those specs should be defined. If we end up using shapes I would push to call them "data shapes specs". | ||
| * RG: I would want to go one step further. We want keep in mind evolvability of those specs. This is not only about defining it but understanding what we want. | ||
| * JZ: Data Domain doesn't do a lot to me, Data Shapes seems very specific. Was Interoperability proposed? The goal seems to be the interoperability. | ||
| * eP: ... | ||
| * PAC: I didn't follow the discussion on Matrix. I agree that C2C may give wrong imperssion. I like the proposal of interoperability. Application Interoperability sums it up from me, and yes I see potential confusion with existing SAI draft. | ||
| * ...: Different applications may have different expectations about shapes or profiles. I would prefer to avoid defining in advance what it would be exactly. | ||
| * HZ: I agree, in LWS we should be very clear not to prescribe anything which would prevent developer to go in one way or another. Less is more in that case. | ||
| * RG: Last week, domain data was preferred but I don't think there is a clear preference now. | ||
| * eP: My point last week was to name it after the goal or promise of what they should acomplish. | ||
| * RG: We want interop with evolvability | ||
| * HZ: There seems to be consensus that C2C needs to be changed, we need to wait for Tim's feedback, ... | ||
| * JW: I would propose to set up a task force to work with developers and converge on the ways of doing that. Having a coordinated environment would help. | ||
| * JZ: Isn't it the data modules group? They have been going through various domains and coming up with specs. Maybe it is more focused on the libraries. | ||
| * HZ: It is not a specific implementation, but what the spec should look like. | ||
| * JZ: It wouldn't be to develop those specs, but to come up with methodology. | ||
| * HZ: Yes | ||
| * HZ: I think practicioners should have a big say. Or at least be consulted. | ||
| * JZ: I will bring it up and everyone here is invited. | ||
| * eP: ... | ||
| * RG: This is the reason why I didn't want to get rid of the STM. The meeting isn't there. You need somebody to take the lead on that specific thing. You need someone to be there to ensure continuity. | ||
| * eP: We should consider what we want to put on CG agenda in January. | ||
| * HZ: I think it depends on WG progress and might be premature. | ||
| * RG: Who would like to take the lead on that? | ||
| * JZ: Isn't it all of us? | ||
| * RG: Who will take the lead? | ||
| * HZ: Do you have someone in mind? | ||
| * eP: I will participate but don't want to lead since I'm editor of SAI and that could create tensions. | ||
| * HZ: You already clarified that you don't want to push SAI. | ||
| * JZ: I want to second that, I wouldn't question Pavlik's ability to separate SAI from whatever we will come up with. | ||
| * RG: I wanted to check with Jesse; you had an application for NLnet, how would that overlap? | ||
| * JW: We applied with Jeff and Jackson Morgan, Tim also signed off on it. We wanted focus on help with publishing shapes, specificaslly SHACL, as well as to improve DX with LDO. However, NLnet haven't accepted it, and modified it. They would like to support Solid. I need to do that in next few days. | ||
| * ...: If we could focus on defining interop-patterns/best-practices/meta-specification. As a work item, name individuals that would work on implementing it in specific domains. We are effectively submitting a new appliation that they will help us fast-track. | ||
| * eP: I can help with leading it. I would sitll like that someone co-leads. Rahul would be great but anyone is welcomed. | ||
| * RG: I might not be the best person, given limited experience with RDF, particulrly shapes. | ||
|
|
||
|
|
||
| ### Summary | ||
|
|
||
| * HZ: Next meeting in January |