I sent another toot this morning pointing to this topic (with an example of Shopping and Shipping domains in a federated app).
And to that I 100% agree. We have this thread Scaling Up Cooperation that’s really not much more than one of the Open Issues of this community at this moment in time. A missed opportunity, while different groups are reinventing wheels.
Currently I believe less in a full-blown semantic web, but I do believe in standardizing on a whole bunch of small closed vocabularies in the Linked Data space. Well, maybe not even standardizing as in ‘adopting a spec’, but move about having a library of design patterns for different domains, where vocabularies are part of the best-practice for each pattern.
For instance on Community and aligning to ValueFlows with @lynnfoster and @bhaugen or - say - entire new fields like PonyUPS, and aforementioned Shopping and Shipping may be library patterns.
The patterns themselves are just knowledge in a growing knowledge base, but they each have a growing list of implementations in various programming languages, API’s and UI component designs (where @Sebastian is also focusing for #software:redaktor-me).
Great that you point to the Use Cases document @bengo - this text had slipped my notice thus far - because, as I see it:
Pattern library: Contains both process + artifacts to design building blocks for Devs representing domain-specific use cases.
(Continuing from earlier today)
The focus on use cases that’s combined in the pattern library is a more hands-on approach than the initial WG document, because we have a fediverse in production to build on and any activity is directly related to practice in the field. It should be ideal for crowdsourcing.
When it is tied to this community (the forum) we can facilitate social interaction here. The community aspect is really important, and indeed championing success / advocating direction. For instance we have a FEP initiative now (thanks to great efforts of @cjs and @pukkamustard), but arguably the process is hard to get under steam without people actively monitoring and rallying things up. But this is time-consuming.
Other than that the use case pursuit can be less bound to direct standards evolution. There are other holes in the fediverse interoperability story where we can place attention in this regard (e.g. privacy, encryption, identity, p2p), probably in different standards.
Exactly. I created #fediversity:fediverse-futures to address the ideation part of this, encourage ‘thinking out of the box’… as a starter. We can just bring stuff up here, and see which ideas are inspiring enough to stick. I see that work like this (video).
The pattern library approach then, is a follow-up that encompasses all the above. Where documents such as a “Smart Vaccination Certificate” - if there’s community interest for that - are gradually elaborated further via crowdsourcing. At top-level there’s only domain knowledge, and a drilldown involves choosing technological directions.
Yes, so should we, AP devs. As it gets too little attention still.
Here it gets really interesting to me. So far, even while we reached out above deeply technical matters, we haven’t really addressed some very important aspects to evolving the Fediverse to a ubiquitous interoperable “social fabric” and that is: the Processes and Methods by which things are woven and stitched together.
I really like those links you mentioned, and - in terms of both involving non-technical people and focus on functionality that truly match their needs - I’d like to introduce another term to this mix, and that is Domain Driven Design. I feel this is a really good match when working with closed vocabularies modeled as AP (or Solid, or what-have-you) extensions.