|
| 1 | +# W3C Solid Community Group: Weekly |
| 2 | + |
| 3 | +* Date: 2025-05-21T14: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 | +* Michiel de Jong |
| 10 | +* elf Pavlik |
| 11 | +* Hadrian Zbarcea |
| 12 | +* Melvin Carvalho |
| 13 | +* Tom Byrd |
| 14 | +* Marc Haddle |
| 15 | +* Jesse |
| 16 | + |
| 17 | +## Regrets |
| 18 | +* CB: [Christoph Braun (uvdsl)](https://github.com/uvdsl) |
| 19 | +--- |
| 20 | + |
| 21 | +## Announcements |
| 22 | + |
| 23 | +### Meeting Guidelines |
| 24 | +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). |
| 25 | +* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). |
| 26 | +* 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. |
| 27 | +* Join queue to talk. |
| 28 | +* 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. |
| 29 | + |
| 30 | +### Participation and Code of Conduct |
| 31 | +* [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/) |
| 32 | +* [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/) |
| 33 | +* 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. |
| 34 | +* If this is your first time, welcome! please introduce yourself. |
| 35 | + |
| 36 | +### Scribes |
| 37 | +* Michiel de Jong |
| 38 | + |
| 39 | +--- |
| 40 | + |
| 41 | +## Topics |
| 42 | + |
| 43 | +### solid/vocab Slowness in approving PRs #96 |
| 44 | + |
| 45 | +https://github.com/solid/vocab/issues/96 |
| 46 | + |
| 47 | +* eP: we may want to address it |
| 48 | +* MdJ: another example, https://lists.w3.org/Archives/Public/semantic-web/2025Mar/0007.html / https://github.com/solid/contacts/issues/8 took one month of back-and-forth. Can we improve how we use semantic web to document our data schemas? Documenting an addition of a term should not take a dev more than 20 seconds. |
| 49 | +* CB (uvdsl): Cant be here today but want to re-iterate https://github.com/solid/vocab/issues/96#issuecomment-2812962755. The fact that the process seems slow is not due to the process. In my honest opinion, it seems slow because of the lack of engagement. Feedback has been given. Request for changes have been made. If there is no progress, it is not the due to the process being the problem but the lack of engagement in the process. |
| 50 | +* ... On #96, app developers can always define their terms and move on if they quickly want to build stuff and move on. The goal of the community vocabularies and more so ontologies in general is that the terms are well understood and have found consensus in large parts of the maintaining community. If app developers really want to have their terms in the general vocabulary/ontology, then the terms should be also deemed useful by other app developers. I suggest to engage with these developers to add to the discussion, to bring the community's awareness to these terms and actively seek feedback. It is the responsibility of the app developer to convince the community that their terms are needed in the vocabulary. It is not the duty of the process to just add new terms whenever people think of a term. It is the goal of the process to build consensus on those terms, what they mean and that they are important to the community - not just individuals. |
| 51 | +* MC: This one is open for 6 years: https://github.com/solid/vocab/pull/57 |
| 52 | +* CB (uvdsl): Why is it still open? Is it still open because there was no feedback or because the feedback was not incorporated? I see three reviews with suggested changes, and one specifically requesting consideration of suggested changes. Why were the suggested changes not incorporated or even discussed? |
| 53 | +#### live discussion |
| 54 | +* eP: First, there needs to be a reference to a report where it's referenced |
| 55 | +* MdJ: what about a reference to running code? |
| 56 | +* MC: Tim wanted to have a wallet section in the Tabulator app. So it needed a class in the typeIndex. So now in my work on wallets I need to choose an rdf class. It's taking a long time to go through the process. Should I make something new or wait for solid/vocab? How do we find out who the 3 reviewers are? And what should we do while we're waiting? |
| 57 | +* MdJ: Agree, you don't want to put it on your own domain, and adding it to a central place like solid/vocab should not take longer than 20 minutes. Definitely not 6 months or 6 years. |
| 58 | +* eP: is that wallet term related to the open wallet foundation? |
| 59 | +* MC: I had the same questions, it seems to be like a calendar-like client-side thing, but it has verification in it. I don't think it's super well defined, but I think a wallet is a place where you put valuable digital assets. |
| 60 | +* JW: what open wallet foundation do is separate from what we do in Solid OS. |
| 61 | +* MdJ: does anyone have experience with publishing RDF terms through them? |
| 62 | +* JW: no |
| 63 | +* eP: agree, we should not expect them to publish RDF terms |
| 64 | +* eP: for general data domains like healthcare, ERP etc, do we want to throw all that in a Solid vocab? Maybe a shape repo? |
| 65 | +* MdJ: if we can't publish our RDF terms then we can't build apps, so then the Solid project is blocked on that. |
| 66 | +* MC: terms in the solid/vocab namespace should be related to a CG work item. Should we create one? |
| 67 | +* eP: that's a possibility, yes. |
| 68 | +* eP: publishing a vocab and a shape should be related. A term that's a 404 has never stopped me from building software. So shapes are probably more fundamental. |
| 69 | +* MdJ: can we use RDF terms that are not URLs? |
| 70 | +* MC: Yes, you can use `urn:json:..` or `urn:rdf:...`. This ties into how developers work. You first prototype the app, then you do the term, then the shape. We should make sure they don't get discouraged. |
| 71 | +* MC: maybe using `urn` terms would fix a big bug in semantic web. |
| 72 | +* JW: using a URL is a process of getting consensus. If we switch to urns then we could be getting into incompatibility |
| 73 | +* MdJ: that's true for urn terms but also for 404 terms |
| 74 | +* JW: we should use neither urn terms nor 404 terms. Use [permid](https://permid.org/) or [w3id](https://w3id.org/). |
| 75 | +* MdJ: agree, using permid or w3id is better than 404 and urn. |
| 76 | +* eP: even if we fix the minting of terms, we will still not have fixed shapes and interop. |
| 77 | +* eP: terms can also change over time. if you quickly define something, as it picks up it's likely to get next versions. If you move fast, you break things. |
| 78 | +* MdJ: yes, we will always need Solid Data Modules and 'lenses'. But we also need a way to mint rdf terms. |
| 79 | +* JW: we have schema alignment and rules for semantic inference, so 'lenses' is a solved problem. |
| 80 | +* eP: as Solid matures, there is no assumptions that people use JavaScript, so we'll need SDM in other programming languages. |
| 81 | +* MdJ: I propose we use w3id from now on. |
| 82 | +* MC: but for Solid Wallet it might be a bad idea because Tim wants it in solid/vocab and he gets it approved, then I'll need to move to that. |
| 83 | +* MdJ: I propose we close Tim's PR then and use w3id from now on |
| 84 | +* JW: Not only w3id, just a pedagogical reminder about ways we can put out vocabs. |
| 85 | +* MdJ: what should a dev do if another dev is already in the slow process of publishing a term? |
| 86 | +* eP: when schemas evolve we can use supersededBy. I agree with Jesse that w3id should not be the only venue, just an example. We should list available options and will be taking on the responsibility to work on lenses etc. I agree that w3id is a more elegant option than 404s and I'm ok with putting out that recommendation |
| 87 | +* MC: At W3C you can publish a whole vocabulary and if they approve it in a few days then you get all your terms. What if we maintain a stopgap vocab at W3C where devs can publish a term in 20 minutes. W3id doesn't actually host the vocab. Let's have a quick tool for it! |
| 88 | +* MdJ: Yes, let's build that! |
| 89 | +* JW: in terms of framing, I wouldn't recommend w3id as the only way. |
| 90 | +* eP: I think we all agree about making the recommendation, but we'll still have other DX problems to solve. Like shapes etc. |
| 91 | +* MdJ: so the question of what to do if a different dev is already in a slow term publishing process (or already using a 404 term), will be an open question |
| 92 | +* JW: next week I can present 30 minutes about inference. |
| 93 | +* MdJ: Cool! I'm also wlrking on lenses: https://tubsproject.github.io/devonian/ |
| 94 | +* eP: Yes, we can iterate on that. |
0 commit comments