|
| 1 | +# W3C Solid Community Group: Weekly |
| 2 | + |
| 3 | +* Date: 2025-05-28T14:00:00Z |
| 4 | +* Call: https://meet.jit.si/solid-cg |
| 5 | +* Chat: https://matrix.to/#/#solid_specification:gitter.im |
| 6 | +* Repository: https://github.com/solid/specification |
| 7 | + |
| 8 | +## Present |
| 9 | + |
| 10 | +* Hadrian Zbarcea |
| 11 | +* [Matthias Evering](https://solidweb.me/testpro/) |
| 12 | +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) |
| 13 | +* Marc Haddle |
| 14 | +* John Kirkwood |
| 15 | +* [Erich Bremer](https://ebremer.com) |
| 16 | +* [Pierre-Antoine Champin](https://champin.net/#pa) |
| 17 | +* [Theo](https://github.com/thhck) |
| 18 | +* Tom Byrd |
| 19 | +* [TallTed // Ted Thibodeau Jr](https://github.com/TallTed) (he/him) mastodon:[@TallTed](https://mastodon.social/@TallTed) (OpenLinkSw.com) |
| 20 | +* Rui Zhao |
| 21 | +* Jesse Wright |
| 22 | + |
| 23 | +## Regrets |
| 24 | +--- |
| 25 | + |
| 26 | +## Announcements |
| 27 | + |
| 28 | +### Meeting Guidelines |
| 29 | +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). |
| 30 | +* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). |
| 31 | +* 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. |
| 32 | +* Join queue to talk. |
| 33 | +* 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. |
| 34 | + |
| 35 | +### Participation and Code of Conduct |
| 36 | +* [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/) |
| 37 | +* [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/) |
| 38 | +* 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. |
| 39 | +* If this is your first time, welcome! please introduce yourself. |
| 40 | + |
| 41 | +### Scribes |
| 42 | +* Pavlik |
| 43 | + |
| 44 | +--- |
| 45 | + |
| 46 | +## Topics |
| 47 | + |
| 48 | +### Update for Solid World |
| 49 | + |
| 50 | +ACTION: eP to create event in CG calendar |
| 51 | + |
| 52 | +* eP: What should I highlight? |
| 53 | +* HZ: Practitioners have their own slot |
| 54 | +* eP: Also WG |
| 55 | + |
| 56 | +### Plans to make teamid.live (Pivot) commercial (a cup of coffee a month via paypal) |
| 57 | + |
| 58 | +* ME: Collisions with the MIT-license? |
| 59 | +* ME: I tried not to make a living but charge a cup of coffee. I have deployed NSS, CSS, and Pivot on different domains. |
| 60 | +* HZ: I'm not a lawyer. MIT and BSD are permissive licenses, similar to Apache. There is nothing that prevents sale of the software with or without modifications. You only can't pretend that you created the sofware yourself. It doesn't prevent you from doing anything you want with monetizing. |
| 61 | +* HZ: There are other commercial offerings like Inrupt, which is based on ESS. |
| 62 | +* ME: I don't plan military-grade security but it is still useful. |
| 63 | +* JW: MIT license shouldn't be an issue. You may want to be careful, based on experience of [solidcommunity.net](https://solidcommunity.net/). Data protection and online safety ... act. I'm working out with ODI what user agreements and application agreements need to be put in place. Also, disclaimers about experimental software and not production-grade security, no penetration testing, etc. I can share it with you, and you can pretty much copy that. |
| 64 | +* JW: ... taking role of data controller under GDPR, and server itself is only data controller. |
| 65 | +* JW: There is also Online Safety Act. We need to figure out whether we need to moderate hosted content. Mastodon community and others in fediverse are also asking this question. There is no precedent in UK where the Safety Act exists. |
| 66 | +* HZ: In US, you can get data insurance. Does anyone know if that is the case in Europe? |
| 67 | +* ME: ... |
| 68 | +* eP: Regarding one person and single point of failure, I recommend contacting indie hosters |
| 69 | +* MH: Regarding insurance, the coverage is global but it matters where potential lawsuits can be brought... Question of "what is the injury?" also matters; for example, financial consequences if somone is down for multiple days. While data is on your server, you have responsibility to protect it. |
| 70 | +* HZ: You will have a lot of things to deal with but the license will not be an issue for you. |
| 71 | +* MH: ... |
| 72 | + |
| 73 | +### Solid catalog shapes |
| 74 | + |
| 75 | +https://github.com/solid/catalog/blob/main/v3/catalog-shacl.shce |
| 76 | + |
| 77 | +* eP: v2 was used for SoSy2025. We are working with Jeff and Jesse on v3. |
| 78 | +* ... it's more of an announcement that we managed to change the shapes syntax, and now we're collaborating on the next version of shapes. Those shapes will also be relevant outside of catalogues. If anybody wants to join, we just wanted to share this update. |
| 79 | + |
| 80 | + |
| 81 | +### [JW] Providing Lightweight infrastructure for publishing Vocabs |
| 82 | + |
| 83 | +* JW: Proposal is to have a repo for vocabs with governance similar to [`definitelytyped.org`](https://definitelytyped.org/) (e.g., if you are first to contribute the vocab, then you're the one responsible for reviewing feedback with core maintainers), and for us to ask W3C to publish vocabs under their name space (e.g., w3c.org/solid/recipes). |
| 84 | +* JW: There is a grant proposal to NLNet that was made to do a similar thing for Shapes |
| 85 | +* JW: We had discussion last week, Michiel wanted to be able publish vocab in 20 min. Extending conversation from `solid/vocab` issues hanging unresolved. |
| 86 | +* JW: There has been discussion on the mailing list, around URN, w3id.org, etc. I had a quick conversation with Tim; we can create `definitelytyped`-style repository. Anyone would be able to create a PR that creates a new vocab document. When you create a new vocab, you become owner of that vocab and are responsible for creating subsequent PRs. Once they are merged into that repo, they would be published in W3C namespace, e.g., `w3c.org/ns/solid/recipes`. |
| 87 | +* JW: We would use it as a way to help us align on the vocabs. |
| 88 | +* eP: I would need to look up the last conversation. I don't think I want to publish terms that may be thrown out in the W3C namespace. There is a risk of getting duplicates, like multiple vocabs for calendars. Is it something for long term, or something that will be thrown away? |
| 89 | +* JW: It is not intended for terms that people will throw away; it is meant for long-lived vocabs. One practice could be that once you start creating an app, you would create a recipes vocab document, and put there any terms that you already stablized. When your term is still early-stage, you would wait to publish it. |
| 90 | +* eP: Who makes the decision whether something is stable? |
| 91 | +* JW: You pretty much trust people. I don't think there will be an issue with creating multiple vocabs. We would create statistics on which vocabs are being used by which apps. |
| 92 | +* eP: I would trust people's intentions, but be careful with their semweb knowledge. |
| 93 | +* JW: We could create a basic set of guardrails. I agree it won't solve all the issues; ontology creation is complex. We could look at having maybe one or two maintainers, possibly with support of ODI. |
| 94 | +* HZ: The enthusiast in me says great. I'm worried about using W3C namespace. People may get the wrong impression about stability based on that. I'm not sure what the *solid* vocabulary means. Do we have infrastructure for it? Do we have a stamp of approval? |
| 95 | +* JW: To respond about W3C namespace, one potential mitigation would be to have a clear warning. W3C could say no, anyway. It would be useful to have a stable home. I was proposing w3id.org, and Tim suggested W3C instead. |
| 96 | +* [TT (after meeting): One advantage of w3id.org is that it's strictly a redirect service, not an actual host environment. Vocabs could change their actual deployment host without breaking any active use. W3C seems an odd host for non-W3C projects, even if Solid sprang from there.] |
| 97 | +* JW: They is nothing special about the vocabs other than the fact that solid apps are using them. There are other ways of doing that as well. I'm trying to solve a problem for application developers by providing a very clear path to publish vocabs and not need to learn about all other infrastructures. |
| 98 | +* HZ: Now it is very clear and I like it. You started with education and tools, being careful not to misguide anyone by the presence of it in W3C namespace. |
| 99 | +* eP: We will not solve it today. We may want to bring this back every week and report on progress. |
| 100 | +* HZ: There is also 'aka' ("also-known-as") |
| 101 | +* TB: My suggestion is to have a clear set of tools and paths. We should also have a peer-review process, so we don't create duplicate vocabularies and dictionaries. There can also be differences in understanding. Medical journals use peer review on their papers. Also developers who have less understanding can get feedback. |
| 102 | +* JW: I agree with the need for tooling. Pitfall that Solid and semweb has fallen into multiple times, was kicking problems down the road and expecting that tooling would solve them. In the near term, we can set up repo-like infrastructure, putting aside where the namespace will be. People could PR shapes and have the peer review and basic linting-type procedures to ensure best practices. It doesn't support finding existing terms, but can allow creation of new ones. We can find and reuse existing ones in the future. |
| 103 | +* HZ: I would like some actions. Do you have any proposals to move it forward? |
| 104 | +* JW: I can take action to set up a new repo or reuse solid/vocab. I could put in place github actions to lint PRs. We also need to work out best practices, RDFS, OWL, etc. I could set up actions to automate approvals and assign reviewers. |
| 105 | +* PAC: I'm concerned about making it available to people and ensuring that we follow best practices. I applaud the initiative. I also wanted to point out, there is a project done by colleagues — Ontology development methodology, https://github.com/Wimmics/olivaw. Probably targeting more semweb aware audience than app developers. |
| 106 | + |
| 107 | + |
| 108 | +### [JW] Vocabs, Ontologies and Shapes (background for above discussions) |
| 109 | + |
| 110 | +* JW: Quick reminder about reasoning, and why we have ontologies. |
| 111 | + 1. Define a formal model of how things relate to one onother and provide semantics. For example, if I know someone, this is a symmetric relation. |
| 112 | + 2. Align meaning of terms. Collaborative and descriptive process. Formally defining them helps with that alignment. Once you have it, you can reason about it using inference. |
| 113 | + |
| 114 | + For example: with OWL, we have a set of rules. I have them here in N3 notation |
| 115 | +* [TT (after meeting): Be cautious with considering things like "I know someone" to be symmetric. Also, with the meaning of "know". RDF predicates based don English lexical stings should not automatically be treated as if the meaning of the English word is the meaning of the predicate, especially where there may be nuances or simply multiple meanings of the English word. I may "know" a musician from the radio, but I need not have ever met them, and they need not "know" me.] |
| 116 | +* eP: These rules? https://www.w3.org/TR/2012/REC-owl2-profiles-20121211/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules |
| 117 | + |
| 118 | +* JW: Showing some reasoning results based on `owl:SymmetricProperty` |
| 119 | +* ... In Solid server, we don't apply any inference; clients/apps would need to apply reasoning to do the inference. We could also use it for schema alignment. |
| 120 | +* ... Shapes come in to allow us to get a view of the data that is useful for the application. When I have a shape which is using FOAF, I can apply inference to get extra facts. |
| 121 | +* [TT (after meeting): Inferred triples should not be automatically accepted as facts. They should be assigned less credence than "physical" triples. It's reasonable to consider them as "propositions", which may be confirmed or rejected by humans or by further inference processes.] |
| 122 | +* JW: Having those shapes, we can use tools like LDO to get objects based on those shapes. |
| 123 | +* eP: When it comes to writing what do you write, what's asserted and inferred? |
| 124 | +* JW: When I write I wouldn't write anything inferred. |
| 125 | + |
| 126 | +### [JW] Schema alignment best practises |
| 127 | + |
0 commit comments