-
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.
Co-authored-by: Hadrian Zbarcea <hadrian@inrupt.com> Co-authored-by: Virginia Balseiro <info@virginiabalseiro.com>
- Loading branch information
3 people
committed
May 30, 2024
1 parent
c093df4
commit e121e05
Showing
1 changed file
with
142 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,142 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-05-22T14: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 | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * [Pierre-Antoine Champin](https://champin.net/#pa) | ||
| * [Rahul Gupta](https://cxres.pages.dev/profile#i) | ||
| * [Laurin Weger](https://mastodon.online/@laurin) | ||
| * Aaron Coburn (Inrupt) | ||
| * Grace Elcock | ||
| * Th | ||
| ## 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 | ||
| * elf Pavlik | ||
|
|
||
| ### Introductions | ||
|
|
||
| * Laurin working on [ActivityPods](https://activitypods.org/) with Sébastien and would like to discuss exporting pods | ||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### WG Status | ||
|
|
||
| * PAC: I want the text of my email to be double checked. I want to send out email to the objectors today. I didn't get any feedback from the council, currently we just need to wait. | ||
| * HZ: I saw mail that we wait for consensus from the CG. Is there any blocker from the CG? | ||
| * PAC: I've got everything I need. TAG has acknowledged reception of the charter. No review yet but it's in their pipeline. | ||
| * HZ: When does the clock start? | ||
| * PAC: The 45 days is the time that the council has to give the decision from when they where conviened. | ||
| * HZ: | ||
| * PAC: So 45 days from 28th of March. | ||
| * HZ: So it is week past 45 days already. | ||
| * PAC: One more reason to reach out to the council chair. | ||
| * HZ: It would be good to get some clarity from the council. | ||
|
|
||
| ACTION: PAC to get update from the council and share it with the CG | ||
|
|
||
| ### Eating our own cookings | ||
|
|
||
| URL: https://virginiabalseiro.github.io/solid-ecosystem-monitor/ | ||
|
|
||
| * eP: CG meetings are one of the few things we do together, instead of scraping the text with minutes we could use the power of Linked Data and maybe even Solid | ||
| * eP: I started a simple prototoype which I would like to use to track my participation: https://github.com/janeirodigital/sai-js/tree/main/examples/plenary#readme | ||
| * eP: In short, minutes are managed as an external attachment, meeting description links to them, all the rest can be managed based on shapes, shapetrees etc. | ||
| * eP: An interesting case for role-based permissions! For example chair can make more changes than a regular CG participant. | ||
|
|
||
| * eP: Sarven came up with the term :). If we could try ourselved to use Solid a bit more. We have this activity monitor that scrapes the minutes. It would be good to use more linked data. One example would be the STM and Practitioner and DX from Fridays. Something like a calendar, marking attendance, scribes, would be something interesting to experiment with. | ||
| * eP: Plenary was developed during the mini-hackathon. It is a good example for using Solid ourselves. | ||
| * HZ: I did get to build and test your project. Pavlik submitted a project to the https://solidhack.org but as co-organizer wasn't competing. I was only able to build his project locally. I don't know if I would use app to do something I can do in web app in one line. | ||
| * eP: I'll try to redeploy it. Yesterday I tried to work with a CDCI with a friend to use ansible to deploy it. I think the point is not necessarily to use this example app, but people to build their own apps and interop. Maybe something like github issues would be useful, but more involved to build. | ||
| * Th: I'm down to try it, if it is a small app is a beggining. I tried dokieli, we could use it to take minutes. | ||
| * HZ: I also tried dokieli and like it. However it was a pet project for Sarven so he throw in everything he needed for himself. I think it doesn't target a specific audience. Also looking at the code it looks like it has been made over long period of time. It could require some cleanup to make it more audience targeted. But again I like what's there already. We should discussi it with Sarven. | ||
| * PAC: One thought, regarding using small stuff that we are doing. It is also in the spirit of unix philosophy. I'm working with some interns on solid app for researches and linguistics. In that app we have a link to penny to let it handle some tasks. Having every new tab not authenticated is very bad UX. There is and obstacle to applying unix philosopy. Building monolithic apps can be better here. | ||
| * Th: Speaking of UI for Solid. I'm forking penny for surfnet deployments. We want to have a usable pod provider we can offer nice experienc with. I'm thinking which app we can use all together. If not dokieli maybe some hackmd like app. | ||
| * eP: I want to emphasise that we shouldn't use the same app, but instead use different apps to collaboerate over the same data. | ||
|
|
||
| ### Meeting with Open Food Network | ||
|
|
||
| * HZ: Solid world was announcde for June 6th. There is PR in solid team repo. | ||
| * HZ: Few weeks ago there was action for me to reach out to Open Food Network, there is a meeting tomorrow. It will be about collaboration between OFN and Solid CG on use cases. One common element is Maxime who is participating in both communities. | ||
| * eP: it would be great to have other use cases that are NOT micro-blogging. Something like supply chains, healthcare, architecture (like TrinPods do). | ||
| * PAC: I have a personal project, Solid app for tracking expenses. I need to collaborate with members of my family on the same dataset. We have local apps that are mobile only. I can share my initial work. | ||
| * HZ: It would be great to have incubator for projects that people want to collaborate on instead just work on them on their own. One of my favorite project was LinkedPro, which looked like LinkedIn. ActivityPods used both ActivityPub and Pods. It gives you social graph and other data on top of it. If anybody is interested in creating icubator we could do it. | ||
| * eP: | ||
| * PAC: FTR, I would love to try and build a Solid app with Leptos https://www.leptos.dev/ 🦀 | ||
| * ...: I'm struggling with OIDC to make a solid app. | ||
| * HZ: Blockchains became very popular, it could help community if there were some ideas on how to monetize solid apps. | ||
| * eP: Solid Practitioners had conversations about monetization | ||
|
|
||
|
|
||
| ### User Profile and Contacts | ||
|
|
||
| URL: https://github.com/solid/webid-profile | ||
| URL: https://github.com/solid/contacts | ||
|
|
||
| * eP: Besides aligning those two efforts, we should also align them with | ||
| * https://www.w3.org/TR/contact-picker/#contact-property | ||
| * https://github.com/fedidcg/FedCM/issues/559#issuecomment-2057657128 | ||
| > Beyond name/email/picture which is currently supported, some of the most commonly asked extensions are allowing RPs to request for the user's phone number (as opposed to email addresses) or the user's language preferences. It is not clear where we could go from there, but we expect a subset of the OIDC's Standard Claims or HTML's autocomplete to be things that the browser could potentially mediate in a constructive way (e.g. organization, country, websites). | ||
| * Contact and the social graph are very important. There is some work on contacts and webid profile. I think now is disjointed. I think there is divergence in the shapes used by the webid profile and contacts. We should try to align that. Adding something in the contacts should mean just adding the webid. The contact picker API ... | ||
| * ... FedCM, the basic functionality people expect from it is, again, basic user information. It would be good to coordinate this work. It's client-client, not in the storage scope, but still, necessary to coordinate. This is more horizontal than vertical, relevant for any domain. | ||
| * | ||
| * HZ: I agree with you. | ||
|
|
||
| ### Standard Pod Export Format | ||
|
|
||
| Laurin Weger: | ||
|
|
||
| > I'm currently implementing a pod export feature for [ActivityPods](https://activitypods.org). | ||
| > I was wondering if others have implemented export features before. | ||
| > Since ActivityPods uses a graph database, we can simply make a SPARQL dump of everything RDF and save it in an n-quads file. This includes the LDP structure and ACL information as well. | ||
| > | ||
| > I can imagine the exported pod to be an archive file looking something like this: | ||
| > | ||
| > - sparql-dump.nq | ||
| > - non-rdf-diretory | ||
| > - file1.txt | ||
| > - file2.jpg | ||
| > - ... | ||
| > | ||
| > The pod structure / "file"-hierarchy is then retained in the ldp triples. I'm thinking that the non-rdf files should have a name that reflects their original URI (or relative URI). This would require some kind of escaping / encoding of the original URIs. Do you have any suggestions or disagree? | ||
| * LW: I wrote a small description above. We use graph database so everyting is either graph or non-rdf resource. What do you think about standardzing some format. We can have either mapping of non-rdf resource IRIs and the directories. Alternative would be to just store the directory hierachy which could be more intuitive if you are in the filesystem based setup. For solid pods, LDP resource repositories need to have hierarchies. We don't require it in ActivityPods. | ||
| * eP: I would have strong preference not to rely on filesystem and keep all the information as metadata. I see slash sematics very problematic and honestly hope the WG will not preserve them. Not being able to reorganize your data without chaning IRIs is not an acceptable approach for me. | ||
| * RG: Unlike Pavlik I have a preference to base it on a filesystem. So whatever you export you should be able to run a pod directly on top of it. I can understand that link will be broken if you are changing domains. I'm working on something at this moment but I can't share it until it gets reviewed. | ||
| * HZ: I find the slash sematics very naive and I hope it will be reconsidered. It may not be as difficult to fix at it seems. There is technology called git, if we look at how it stores data. The hierachy is just a view. Git allows you to have multiple views. I would like similar approach for Solid. | ||
| * PAC: I'm not sure I understand everything with the issues that you two raised. I don't have issue with that. Slashes are part of IRIs, the fact that links break don't seem related to slash sematic. The slash semantic says that if uri ends with a slash they are containers. I don't see a serious problem. I think you can as easily break links with or without slash sematics. | ||
| * AC: I think we could go round in circles. Everyone on this call has strong opinions. I think if it is purely to focused on the questions if they should be or not we can't answer it. We need use cases and requirements. Slash semantics would be just one possible way to address those requirements. I don't see it useful to discuss it without having UCR. | ||
| * RG: Can we get back to the original question. | ||
| * HZ: In the caes of SPARQL dump I don't know it it is neccessary, ... could be recreated. | ||
| * eP: We have currently triple store only but the idea is to use graph names as resource names | ||
| * HZ: Who finds it an important topic | ||
| * many hands up | ||
| * RG: Question I have for you, do you feel need for standard format? How do you plan to transfer pod to another storage? If you to do it on the client, it is irrelevant since it uses solid protocol. | ||
| * LW: Jeff has shared link to software which does something as you requrie. For now we are doing it on the backend. | ||
| * PAC: Rahul mentioned that as long as you preserve data everything is fine. Do we want to use absolute iris or relative iris. But it can bee tricky to ensure all are relative. What is the invormation that you want to convey. | ||
| * HZ: I see a big problem with linked data. We have identity and location, URI and URL. If some address breaks the data still could be available. Addresses change identities don't have to. I don't think Solid models those realities well. | ||
| * RG: For Laurin's case you can ... The only task is migration, you need to massage the IRIs. | ||
| * PAC: If the question is standardizing an exchange format we should go beyond it will do the job for you. | ||
|
|