Commoning Engine

[balkansalat]

Ich versuche gerade, zu einem Entwurf zu finden, der mit den wenigen Mitteln, die wir haben (werden), machbar erscheint und die Chance verspricht, dass das Ergebnis brauchbar sein könnte.

Auf dem Weg dahin ist mit Unterstützung von @Marcus folgende Grafik entstanden:

Die Datenbanken auf der rechten Seite (hellblau) können wir als gegeben annehmen. Zumindest scheint es bisher möglich, sie mit bestehender Software zu realisieren.

Der Mittel-Hub (dunkelblau) ist nur ein unscheinbares Stück Software, welches vermutlich leicht und schnell zu realisieren ist, wenn es notwendig wird.

Das Herz des Backends ist die rote Commoning Engine. Sie definiert die Datenstrukturen, die zur Abwicklung von Bedürfnisbefriedigungsprozessen notwendig sind. Und ermöglicht via API die entsprechenden Operationen, um mit Bedürfnissen und Tätigkeiten umzugehen.

Auf dem Weg zu einer Referenz-Implementierung habe ich eine Art Prototyp erstellt: Bisher nur ganz wenig Code, im Wesentlichen werden das Datenmodell und die API festgelegt. Aber es lässt sich bei diesem Umfang bereits ein vollständiger Bedürfnisbefriedigungsprozess daran durchspielen. Der Quelltext ist hier zu finden:

Robert / Commoning Engine · GitLab

Damit wird das Projekt nun endlich überschaubar: Der wesentliche fehlende Teil ist ein gutes Frontend. Darin steckt viel Arbeit, aber wenn wir gut vorarbeiten, ist das für eine_n erfahrene_n Frontend-Entwickler_in relativ leicht machbar.

Die anderen Komponenten können wir währenddessen probeweise in Betrieb nehmen, schrittweise verbessern und so weiter.

[Raffael]

Ok, das klingt ja superspannend! Aber so wirklich vorstellen, was das nun heisst, kann ich mir trotzdem nicht wirklich…

Ich würde gerne bei einem der nächsten Meetings die Grafik gemeinsam anschauen und die Schlüsse daraus nachvollziehen können. Wenn ichs richtig verstehe, können wir durch diese Grafik auch unsere Anforderungen an die Software und für die Firmen genauer spezifizieren, richtig?

Eine Frage hab ich jetzt schon: Weshalb hat es zwei Frontend UI1 und UI2?

[balkansalat]

@raffael

Eine Frage hab ich jetzt schon: Weshalb hat es zwei Frontend UI1 und UI2?

Du kannst auch drei oder vier hinmalen - oder nur eins. Es soll nur andeuten, dass wir gleich mitdenken, dass es verschiedene Ansichten evtl. auch auf verschiedene Teile des Systems geben kann. Zu Anfang werden wir froh sein, wenn wir ein einfaches Interface haben, welches den ersten gewählten Anwendungsfall gut abdeckt.

[Raffael]

Hihi, ach so, alles klar!

[Marcus]

Ich kann mich da Raffael anschließen: Ich finds richtig cool, kann die Tragweite aber nicht ganz fassen. Aber soweit ich noch den Prototypen im Kopf habe und wenn ich mir jetzt vorstelle, dass über die Engine jetzt wirklich ganze Prozesse zur Bedürfnisbefriedigung hergestellt werden können, dann ist das richtig geil. Lass das gerne mal als Hauptthema besprechen, wenn wir uns das nächste Mal treffen.

[Marcus]

While working on the project.-page, I felt the need to bring the graphic to a new state. It was especially important to me to break down the engine a bit and especially to show its result isolated (proposed activities), because it refers again to other data. And of course the introduction of the reputation extractor/adapter as a single module.

Brief introduction as I think of it:

databases

Distributed means and reputation databases that are read via extractors/adapters and made equally processable. The “means e/a” thereby sends information back to the “means-databank” for use/agreement on the means. The “activity-pattern-database” is referred to in the proposed activities. The “reputations a/e” ties various reputation systems to user profiles.

needs / demands / problematic state of means

These are three forms of problems, which can trigger activities to solve them. What is exciting is that they come from three different sources. “Needs” are fed in directly by users. “Demands” are created by self-assignment to “proposed activities” and are then part of “configurations”. “Problematic states of means” are mediated by the “means extractor/adapter” if a “conservation state” (bad translation) has been defined before. The three forms of problems are passed to the engine.

Engine

The engine is the algorithm of the configuration process. At the end of the day, it does nothing more than propose activities (“proposed activities”) based on the locally available resources and the three problem cases that stakeholders can take on.

Proposed activities

The static set of all proposed activities. Activities are proposed to users according to their availability of resources, according to their skills/interests, and according to their specified consideration (“Berücksichtigung”). Each activity refers to a pattern of the “activity-pattern-database”. If activities are assigned, they become part of the “configurations”.

Configurations

The context of activity patterns that have been assigned to ultimately satisfy mediated needs. It is a transparent arrangement of patterns from the activity pattern database.

User-ID

Present twice in the image, for clarity. It’s about unique user profiles - The top means: users mediate needs and communicate to agree on configurations or make agreements on the use of resources or the definition of conservation states. The “User-ID” below means: In the profiles one’s own circumstances, social relations, reputations are recorded. Depending on this, one’s needs are displayed to other users according to their preferences, or activities are highlighted according to one’s considerations. Users can assign themselves to the “proposed activities”.

User-Interfaces

In user interfaces, various information that arises in the process can be made available. For example, suggested activities. Or transparency of configurations. Or communication. Or anything. In different forms, as smartphones or web apps, etc. pp. The main thing is to display information and, in the best case, enable interaction with it.

non-software interface/connection

Software mediation can’t be decided solely on the use of resources. It needs interfaces to non-software users. At least the information about their planned use and possibilities of contacting etc., if there is a conflict about the use or someone wants to use the means who is not a user.

Did I miss something relevant? Do you disagree with something? Especially, but not exclusiv, @balkansalat and @qsmd .

I also hope it helps us structure our " environment analysis"/Umfeldanalyse.

[balkansalat]

Thank you. The new graphic reflects the state of the discussion quite well. I wouldn’t add or change something at the moment.

[Marcus]

We have an ongoing dispute here in the house about a garden that actually belongs equally to all the people in the house, but to which one family has special claims for particularly historical reasons and is trying to enforce them. Why doesn’t matter, but a process is being initiated to clarify the use of the garden. What has become clear to me is, of course, that after such a clarification, a notice is needed stating which rules of use, etc. have been agreed upon, how long they may last, between whom they were agreed upon, and who is the contact person if they are to be changed or if there are violations of the rules. But such a notice of course becomes outdated and ideally there is a source for this notice that can be retrieved at any time. So, I’d best enter the address of the house somewhere and if I have the appropriate rights, I can see what agreements were made by the house community. And this database would be the exact same thing that we need in the software infrastructure and is put on the means to get agreements on their use transparent.

I therefore see an “agreement databank” as a separate building block in our software infrastructure. I don’t know of any such (open) databases , but there will be several of them, which again have to be made processable via an “adapter/extractor” and directly related to the extractor/adapter of the means-database.

Added an “agreement database” and an “agreement adapter/extractor”.