General vs domain-specific interoperability

[woutermont]

Creating this discussion as a central place for the points raised in solid/chat#1 and #553 (comment), which @elf-pavlik proposed to look into during the CG call of August 16th.

---

The main point of discussion is whether or not Solid CG specifications should include domain-specific models for interoperability, given that it will already include general models of interoperability.

To quote @elf-pavlik and @timbl in solid/chat#1:

[@elf-pavlik:] In Solid Application Interoperability we don't expect every domain to need its own domain-specific specification. Interop pretty much depends on domain-agnostic SAI spec and domain-specific ShapeTrees (which in turn depends on data shapes).

[@timbl:] Every domain has to typically make is own spec for its own applications. If tools like shapes or SAI or shapetrees make that easier then they can use that. But in most domains by far the need is to map existing non-solid standards into linked data in Solid pods so that data can imported, exported and ideally synced with external systems. Existing well used standards like VCARD, iCALENDAR, OFX, GPX, FHIR, and hey for chat Matrix, involve typically a lot of work to build consensus and have a lot of value. Making the most straightforward mapping is important.

[woutermont]

My personal opinion is that the CG/WG should focus on building general frameworks for interoperability, and should not create domain-specific models/specifications. A number of considerations make me lean strongly to this side:

• Given the immense amount of specific domains, each with their share of stakeholders, any choice of particular inclusion in the CG will be an arbitrary and unfair allocation of attention and effort.

• Given that immense amount of specific domains, effort is quite probably better spent providing general interoperability models into which any stakeholder can easily plug domain-specific models when they feel the need for those.

• A lot of effort has indeed already been spent towards that direction, e.g. in the initial idea of Type Indexes, and more broadly in the work of the Solid Application Interoperability specification.

• It is Solid's aim to empower people in making informed decisions when controlling their data. To achieve this, interoperability models should include an agreed upon way for deriving human-readable descriptions of the semantics of data during authorization flows. A general specification that describes such a mechanism can provide an extension point for any number of orthogonal modelling languages (e.g. ShaCL, ShEx, ShapeTrees). This is a basic separation of concerns.

• Domain-specific modeling is best left to experts of that domain. Instead of creating specific models for arbitrary domains we are interested in, stakeholders entering the Solid ecosystem could use a general framework that allows them to easily create their domain-specific interoperability models on top of it, using any compatible language, at the moment that they want to engage. This way, we allow such models to grow organically within each domain, while at the same time guaranteeing the necessary semantics for Solid (including the human readable descriptions needed to inform the user during access control).

That being said, I am not at all opposed to efforts on domain-specific models within the Solid Project (but not as part of the CG/WG). I would only caution those efforts not to rely on their models to remain compatible with Solid if they completely sidestep the general frameworks the CG/WG is working on. Maybe it would be wiser to first work together on such a more general framework, and only then define implementation models for it in specific domains.

[woutermont]

For those interested, at today's meeting (minutes upcoming), a special topic meeting on the alignment on generalized approach to client-client specs has been proposed on Tuesday 2023-09-19 (at 14:00 UTC).

I'm closing this discussion for now, keeping it as input for that meeting.

[TallTed]

@woutermont -- That special topic meeting link is wrong. This is the correct link.