Re: Chairs election

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