Re: Chairs election

All are invited to the next Solid Practitioners virtual meeting this
Thursday, 5 February, at 15:00 UTC/GMT. The subject is part two of our
exciting sessions on Solid in relation to food distribution and food
security.  We'll hear from Tom Byrd whose Baltimore Food Project aims to
use Solid to help network small farmers, distribution centers, and those in
need of food in the large global majority communities in and around
Baltimore, USA.  We'll also hear from Luke Dary, of Redhat, on his goal to
create an app to help those in need find local sources of food.

No special software, preregistration, or technical knowledge is required to
join.  Just point your browser at https://meet.jit.si/solid-practitioners.
For more about the Practitioners group, see
https://github.com/solid-contrib/practitioners.

-- 
Jeff Zucker
Founder/co-chair Solid Practitioners
Member ODI Solid Advisory Committee

On Wed, Nov 19, 2025 at 11:35 AM Christoph Braun <braun3@fzi.de> wrote:

> Hi Jeff,
>
> I am excited to see the self-nominations for CG chair, thanks to all for
> volunteering.
>
> Thank you for chairing the Solid Practitioners!
>
>  In my mind the most important issue for the CG to tackle is the creation
> of client-to-client specifications such as the one TimBL has created for
> chat. These are a fundamental part of the interoperability of the Solid
> ecosystem and are connected with the development of shapes for various
> domains.
>
> So, I would like to ask everyone who is nominating for chair to say a few
> words about your understanding of client-to-client specifications and how
> you see your involvement in their development.
>
> Absolutely. These specifications are really the fundamental piece to
> achieve interoperability among/between applications.
>
>
>     WHAT client-to-client specifications are to me
>
> Reading through the Solid Chat specification [1], I mainly see two
> elements:
> 1. defining data models, i.e. specifying the vocabulary (or terms) and
> defining corresponding shapes
> 2. defining operations/actions/interactions protocol, i.e. specifying the
> expected interaction with data instances, how they might be
> modified/extended/...
>
> I fully support the idea of defining specific common data models that can
> be re-used by, across and between applications.
> I appreciate the explicit definition of how the specification authors
> expect data instances to be modified.
> However, I am afraid that these expectations might not be enforceable
> purely on the client-side, as not all apps may adhere to a specific
> client-to-client standard and still re-use such a data instance.
> Maybe a corresponding enforcement mechanism on the server-side might be
> necessary in combination, e.g. shape validation on pod-stored resources.
> Therefore, I believe that these specifications enable client-to-client
> interoperability, but may require server-side support (e.g. shape
> validation) to be truly robust.
>
> FWIW, other projects have similar concepts, e.g. the Asset Administration
> Shell (AAS) from the Industrial Digital Twin Association (IDTA) / Plattform
> Industrie 4.0 calls theirs "submodel templates" [2].
> For those interested, it might be valuable to review how they tackled
> these specifications - to see if their patterns can be adapted for Solid.
>
>
>     HOW I see the co-chairs' involvement
>
> I believe the co-chairs' responsibility is to foster consensus about
> (details of/in) those specifications, which are drafted and put forward by
> their respective editors/authors.
> Any member of the CG may propose such data model / client-to-client
> specification to the group, find contributing members and excite other
> people about it!
> I'd hope that maybe the members of our Solid Practitioners could lead the
> charge here, proposing those data models (and related items) that they
> already use for broader adoption.
> For me personally, I'd be happy to provide feedback and to facilitate
> finding potential collaborators when a new specification is proposed.
> In the end, however, I see the co-chairs role not as the driving (or
> writing) force behind those specifications but rather as the helping hands
> to find consensus in the community to help the specification
> editors/authors to mature their specification.
>
>
> This is just my current take on this, I am happy to receive any feedback
> or discuss your expectations around this topic!
>
> Cheers
> Christoph
>
>
> [1] https://solid.github.io/chat/
> [2] https://github.com/admin-shell-io/submodel-templates
>
>
> Thanks!
>
> --
> Jeff Zucker
> Founder/Co-Chair, Solid Practitioners
> Member, ODI Solid Advisory Committee
> Maintainer, Solid Resources Catalog
>
>
>