Software-Komponenten

Ununterbrochenes Commoning Diskussion
1

Ausgehend von der folgenden Beschreibung haben wir weiter unten eine Grafik entwickelt. Im Beitrag zur Commoning Engine wird diese erstmalig beschrieben und die Struktur damit neu definiert. Dieser Beitrag dient dennoch als wichtige Referenz für einige Details.

Die Software lässt sich in Bausteine zerlegen. Idealerweise definieren die Komponenten klare Schnittstellen. Unter Berücksichtigung dieser Schnittstellen können sie dann weitestgehend unabhängig voneinander entwickelt werden, es ist auch kein Problem, wenn sie sich technologisch unterscheiden.

Dieses Dokument ist Work in Progress, es ist also nicht fertig. Bei der Diskussion verfasst bitte separate Posts zu den einzelnen Komponenten, dann lässt sich die Diskussion leichter moderieren.

Komponente (1): Wissensdatenbank

  • Kapselt den Zugriff auf eine oder mehrere Wissensdatenbanken (mit oder ohne Cache).
  • Prominentes Beispiel ist Wikidata, diese sollte in jedem Fall angebunden werden.
  • Weitere Datenbanken decken typischerweise domänenspezifische Teilbereiche ab (beispielsweise MusicBrainz)
  • Komponente concepts des Mini-Prototypen
  • Schnittstelle (1a):
    • Anfrage von Begriffen und den zugehörigen Beziehungen (Taxonomie)
  • Schnittstelle (1b):
    • Aktualisierung der Wissensdatenbank

Komponente (2): Mitteldatenbank

  • Kapselt den Zugriff auf alle verwendbaren bestehenden Mitteldatenbanken (beispielsweise für Lastenfahrräder).
  • Legt zusätzliche Mittel in einer eigenen Datenbank ab.
  • Implementiert APIs wie die Commons API, sowohl zum Zugriff auf externe Datenbanken als auch um eigene Mittel nach außen anzubieten.
  • Ordnet jedem Mittel ein Mittelmuster zu (unter Verwendung der Schnittstelle (4a)).
  • Ermöglicht eine „Reservierung“ von Mitteln.
  • Komponente means des Mini-Prototypen
  • Schnittstelle (2a):
    • Anfrage von vorhandenen Mitteln (auf Grundlage eines Mittelmusters)
    • Reservierung von Mitteln
    • Ob die Commons API hierfür verwendet werden kann, muss geprüft werden.
    • Im Prinzip handelt es sich um einen Commons Hub (siehe auch).
  • Schnittstelle (2b):
    • Hinzufügen und Entfernen von Mitteln
    • Verändern von Mitteln (evtl. teilweise auch in (2a))
    • Ob die Commons API hierfür verwendet werden kann, muss geprüft werden.
    • Im einfachsten Fall kann das der Zugriff auf eine eigene Commons Booking Instanz sein, die alle Mittel verwaltet, die nicht von externen Plattformen kommen.
  • Schnittstelle (2c):
    • Anfrage von (privaten) Mitteln eines Benutzers
    • Privatsphären-relevant

Komponente (3): Tätigkeitsmusterdatenbank

  • Legt Tätigkeitsmuster strukturiert ab.
  • Ein Tätigkeitsmuster umfasst mindestens:
    • Beschreibung des Ablaufs der Tätigkeit
    • Das Resultat der Tätigkeit in Form eines Mittelmusters (Verwendung der Schnittstelle (4a))
    • Die Bedarfe der Tätigkeit in Form von Mittelmustern (Verwendung der Schnittstelle (4a))
  • Tätigkeitsmuster müssen versioniert werden, jede Version muss eindeutig zugreifbar sein.
  • Beispiele für Tätigkeitsmuster finden sich auf wikihow.com. Auch Open Source Ecology kennt etwas in der Art.
  • Falls es verwendbare externe Musterdatenbanken gibt, sollten diese eingebunden werden. Beispielsweise wikihow.com (Lizenz, API).
  • Komponente patterns des Mini-Prototypen
  • evtl. Realisierung auf Basis von MediaWiki möglich
  • Schnittstelle (3a):
    • Anfrage von Tätigkeitsmustern auf Grundlage des Mittelmusters von Resultaten
    • Auslieferung nach dem Commons-API-Schema an (2) Mitteldatenbank (Commons Hub)
  • Schnittstelle (3b):
    • Anfrage von Tätigkeitsmustern mit Bedürfnisbefriedigung als Resultat
  • Schnittstelle (3c):
    • Hinzufügen und Verändern von Mustern

Komponente (4): Mittelmusterdatenbank

  • Zentrale Komponente, die mit den Komponenten (1), (2) und (3) zusammenarbeitet.
  • Stellt für jedes Mittel ein Mittelmuster bereit.
  • Stellt für Resultate und Bedarfe von Tätigkeitsmustern Mittelmuster bereit.
  • Ordnet jedem Mittelmuster einen Begriff der Wissensdatenbank zu (Verwendung der Schnittstellen (1a) und (1b))
  • Schnittstelle (4a):
    • Anfrage von Mittelmustern, bei Bedarf wird ein passendes Muster erstellt

Komponente (5): Matching und Konfigurationen

  • Ermöglicht die Zusammenstellung von Tätigkeitsmustern und Mitteln zu Konfigurationen.
  • Schnittstelle (5a):
    • Anfrage von Konfigurationen für ein Tätigkeitsmuster nach bestimmten Kriterien
    • Dazu Verwendung der Schnittstellen (1a), (2a), (3a) und (4a)

Komponente (6): Bedürfnisdatenbank

  • Ablage von Bedürfnissen der Benutzer.
  • Komponente needs des Mini-Prototypen
  • Schnittstelle (6a):
    • Erstellen von Bedürfnissen
    • Schließen von Bedürfnissen
    • Abfrage von Bedürfnissen eines Benutzers
    • Privatsphären-relevant
  • Schnittstelle (6b):
    • Abfrage aller Bedürfnisse

Komponente (7): Benutzerdatenbank

  • Typische Benutzerdatenbank mit Registrierung.
  • Legt Reputationskonten ab.
  • Komponente accounts des Mini-Prototypen
  • Schnittstelle (7a):
    • Anlegen und Löschen eines Benutzers
    • Abfrage der Eigenschaften eines Benutzers
    • Privatsphären-relevant

Komponente (8): Standard-Benutzerschnittstelle

  • Vermutlich im Wesentlichen für mobile Endgeräte (App)
  • Einfache Benutzerverwaltung (Schnittstelle (7a))
  • Verwaltung der eigenen Bedürfnisse (Schnittstelle (6a))
  • Verwaltung der von Mitteln (Schnittstellen (2b) und (2c))
  • Zuordnung zu Tätigkeiten
  • Kommunikationsfunktionen

Komponente (9): Verwaltungsbenutzerschnittstelle

  • Schnittstelle für fortgeschrittene Benutzer
  • Evtl. eher als Desktop-Webanwendung
  • Verwaltung von Tätigkeitsmustern (Schnittstelle (3c))
  • Verwaltung aller anderen Komponenten (insbesondere auch (1)), sofern nicht über Komponente (8) abgedeckt
  • Evtl. könnte jede Komponente eine Art Plugin definieren, mit welchem sie Verwaltungsfunktionen für diese Oberfläche anbietet.
  • Könnten zunächst die einfachen Views und das Admin-Interface des Mini-Prototypen sein.

Fehlende Komponenten

Es fehlen noch eine oder mehrere Komponenten für folgende Funktionen:

  • Zuordnung von Tätigkeitsmustern zu Bedürfnissen (Verwendung der Schnittstelle (3b))
  • Freischaltung von Konfigurationen für Bedürfnisse (Verwendung der Schnittstelle (5a))
  • Zuordnung von Benutzern zu den Tätigkeiten einer freigeschalteten Konfiguration
  • Aktivierung von Konfigurationen
  • Abschließen eines Bedürfnisbefriedungsprozesses (siehe auch (6a))
  • Kommunikationsfunktionen
1 „Gefällt mir“
2

Hammer! Geil, dass du das herausgestellt hast, ich liebe das gerade wirklich. Bin immer noch auf dem Treffen des CI und habe nicht so viel Kopf und so weiter, aber richtig cool! Sieht super nützlich aus!

3

@fkleedorfer, kannst du in diesen Komponenten irgendwo Elemente des WoN wiederfinden?

4

Ja:

Unter Komponente 1 (Wissensdatenbank) würde ich einfach das gesamte Linked Data Universum verstehen. also zb. wikidata, wikipedia, schema.org, yago, aber auch jedes einzelne RDF file, das irgendwo rumliegt, zb. auf github.

Komponente 2: (Mitteldatenbank) ist in meiner Vorstellung die Gesamtheit aller WoN-Atoms, die mit der Absicht (und entsprechendem Dateninhalt) gepostet wurden, Mittel für das Commoning zu repräsentieren. Zb mein Fahrrad: https://www.matchat.org/owner#!post/?postUri=https://node.matchat.org/won/resource/atom/lsziktn219kk … also keine normale Datenbank, vielmehr, alles, was sich im Web findet und das Protokoll spricht. Um zum Ausdruck zu bringen, worum es geht, bezieht sich die Beschreibung des Atoms auf die „Wissensdatenbank“. Z.B. nutzt die Beschreibung meines Fahrrads (https://node.matchat.org/won/page/atom/lsziktn219kk) u.A. das schema.org Vokabular.

Analog dazu wäre die Komponente 6 (Bedürfnisdatenbank) die Menge aller Atoms, die Bedürfnisse repräsentieren.

Komponente 3 (Tätigkeitsmusterdatenbank) und Komponente 4 (Mittelmusterdatenbank) wären Vorlagen für das Erstellen von Atoms in WoN. Hier nicht aufgeführt, aber durchaus nützlich wäre eine Komponente „Bedürfnismusterdatenbank“, die Vorlagen für Bedürfnisse enthält. (Nur nebenbei: damit wird - möglicherweise langwierig - gelerntes Wissen über die Möglichkeiten der Bedürfnisbefriedigung erfasst, wiederverwendbar und interpersonell vermittelbar gemacht) Schön wäre, wenn es für all diese Postings Vorlagen gäbe, die man an einer zentralen stelle veröffentlichen und warten kann (zb. in einem github repo), und die von allen clients sofort genutzt werden können. Ist aber technisch schwierig; bisher haben wir templates gebaut, die man recht einfach erstellen kann, die aber fix mit der Webapplikation ausgeliefert werden.

Komponente 5 (Matching und Konfigurationen) - dafür müsste eine Musterinstanz (aus einem Muster der Musterdatenbank) erzeugt werden. Ich hab mir noch nicht genau überlegt, wie man das am besten mit unserem System abbilden würde, aber ich probiers mal: Die Musterinstanz hat für jede benötigte Verbindung (Mittel und Tätigkeit bzw. Person(?)) einen ‚socket‘ in der Beschreibung der Musterinstanz, sowie Einschränkungen für die matches, die dafür erwartet werden. Mit diesen Informationen suchen WoN-Matcher in ihren Datenbanken nach passenden Atoms (Mitteln, angebotenen Tätigkeiten/Personen, und anderen Musterinstanzen) und meldet die an die Musterinstanz zurück. Diese Musterinstanz wird entweder von einer Benutzer*in oder einem Bot gesteuert und wählt die Verbindungen aus, die sie will, oder umgekehrt entscheiden die Bots/Personen, die die gefundenen Atoms steuern, ob sie da mitmachen wollen. Sobald die Musterinstanz alle nötigen Verbindungen hat, können sich die jeweiligen User/Bots koordinieren, um zu tun, was immer da zu tun ist.

Komponente 7 und 8 kann man natürlich neu bauen, die von uns entwickelte prototypische Webapp kann halt schon einiges.

5

Danke für deine ausführliche Antwort, @fkleedorfer, ich freue mich sehr. Ich hoffe, du hast etwas Geduld mit mir, ich kenne leider die Begriffe des Semantic Web nicht besonders gut. Ich hoffe aber, dass ich über diesen Austausch ein besseres Gefühl für das WoN bekomme.

An alle anderen: Lasst euch nicht abhalten, die Komponenten auch unabhängig vom WoN zu diskutieren. Mit den Moderationsfunktionen können wir die Diskussion problemlos in mehrere Threads aufteilen, falls es zu unübersichtlich wird.

Linked Data, wieder was gelernt. :slight_smile: Ja genau, ich denke, das meine ich auch, nur dass ich mich damit nicht so gut auskenne. Die Komponente (1) ist so gemeint, dass sie alle (oder vermutlich eher einige) dieser Datenquellen unter einer für unsere Anwendung passenden Schnittstelle verfügbar macht. Wenn dein Fahrrad irgendwo zwischen „Fortbewegungsmittel“ und „Rennrad“ semantisch eingeordnet werden soll, durchsucht die Software ja nicht erst das ganze Netz, welcher Datenbestand einen passenden Begriff haben könnte.

Interessant. Angenommen, es wären bereits solche Atome gepostet worden, kann ich die dann über eine definierte Schnittstelle anfragen? Und ebenso neue hinzufügen?

Kannst du mir die Stelle zeigen/ beschreiben, an der gesagt wird, dass es ein Fahrrad ist? Ich habe sie gesucht, konnte sie aber so einfach nicht finden.

Ja, alles klar, ich bekomme langsam ein Gefühl für das Prinzip. Auch hier möchte ich die Fragen stellen, die ich oben zu den Mitteln schon gestellt habe: Kann ich die über eine definierte Schnittstelle anfragen? Und ebenso neue hinzufügen?

Für weitere Fragen und Gedanken mache ich separate Posts auf.

6

Das heißt: Eine konkrete Tätigkeit, die jemand ausführen kann, wäre wieder ein Atom, richtig?

Tätigkeitsmuster sind für mich beim Ununterbrochenen Commoning ein sehr zentraler Aspekt. Sie müssen für alle Menschen einsehbar und auch veränderbar sein. Nicht nur für technisch versierte Menschen. Daher braucht es einen passenden Speicherort mit Versionierung und eine Benutzerschnittstelle, damit die Evolution der Muster sichtbar wird, Menschen auf bestimmte Musterversionen referenzieren können und sich lokal unterschiedliche Arten des gleichen Grundmusters entwickeln können. Das alles passiert ohne Steuerung oder Kontrolle „von oben“. Zusätzlich haben Tätigkeitsmuster weitere Eigenschaften wie beispielsweise den Aufwand, der ebenfalls im Rahmen von Komponente (3) ermittelt und abgelegt werden muss.

Konkrete Tätigkeiten, die nach einem bestimmten Muster ausgeführt werden, müssen auf das Tätigkeitsmuster verweisen. Dieser Zusammenhang ermöglicht zu ermitteln, welche Muster häufig verwendet werden und wer welche Muster ausführen kann.

Ein Tätigkeitsmuster besteht mindestens aus der Tätigkeitsbeschreibung, dem Ergebnis und den Bedarfen. Für das Ergebnis und die Bedarfe reicht eine Beschreibung als Referenz auf die „Wissensdatenbank“ nicht aus. Wenn das Ergebnis eines Musters „10 Liter frischer Erbeersaft im Kanister“ ist und der Bedarf eines anderen Musters „5 kg Fruchtsaft“ ist, dann würden die Matcher vermutlich auf Grundlage der Verbindung „Erdbeersaft“ ist „Fruchtsaft“ aus der Wissensdatenbank entscheiden, dass sich Resultat und Bedarf verbinden lassen. Aber tatsächlich müssen sie alle Informationen haben, um tatsächlich eine möglichst gute Entscheidung treffen zu können. Daher ist für mich „Erbeersaft“ mit der Mengenangabe „10 Liter“, der Zustandsangabe „frisch gekeltert“ und der Verpackung „Kanister“ ein Mittelmuster.

Nun bleibe ich gerade an der Überlegung hängen, wenn WoN Matching auf Ebene der Atoms macht (verstehe ich das richtig?), ob dann die Mittelmuster nicht Atom sein müssten.

7

Im Falle von Linked Data sind diese Daten bereits verfügbar, es geht eher darum, sie zu verwenden, um eine GUI für Eingabe/Anzeige zu generieren. Das wiederum kann eine höchst knifflige Angelegenheit sein.

Zunächst: WoN ist ja kein zentralisiertes System, also kann es durchaus sein, dass instanzen betrieben werden, auf denen solche Atoms liegen, von denen ich nichts weiss. Du kannst jederzeit selber neue hinzufügen, indem du auf einem WoN Node (einem server, der die Atoms verwaltet) so eines anlegst - zb mit der Webapp auf https://matchat.org. So ein WoN Node hat selber keinen index von Atoms, den man durchsuchen könnte, aber man kann die atoms crawlen und analysieren - das ist die Aufgabe der Matcher. Ein Startpunkt wäre https://node.matchat.org/won/page/atom Es spricht aber nichts dagegen, dass ein Matcher auf einer Website eine Indexsuche anbietet.

Nein. Das Objekt hat die Typen won:Atom und s:Offer (won: und s: sind nur abkürzungen für längere URIs), dass es sich um ein Fahrrad handelt, wurde nicht über spezielle Typen/Eigenschaften ausgedrückt. Wenn du auf matchat eine Wohnung suchst, ist das anders. Das liegt daran, dass wir diesen Fall vorgesehen haben, für das Fahrrad musste ich aber auf ein generisches ‚Angebots-Posting‘ zurückgreifen.

Selbe Antwort wie oben.

8

Für die Komponente (2), die Mitteldatenbank, gibt es bereits Code. Das Commons Booking Projekt erstellt für velogistics.net einen CommonsHub.

1 „Gefällt mir“
9

Ich habe nun eine einfache Grafik entworfen, die einige grundlegende Strukturen visualisieren soll. @Marcus hatte angedeutet, dass du dir vorstellen kannst, sie hübsch zu machen. Das würde mich freuen.

Wir werden sie auf jeden Fall gleich das erste Mal bei den kommenden Gesprächen mit den externen Software-Menschen verwenden.

Transcomm-Struktur

1 „Gefällt mir“
10

Kann ich machen. Wobei ich sie wohl nur ein bisschen „säubern“ würde, um nicht irgendwelche Gedanken von mir bzw. Unstimmigkeiten reinzubringen.

Wohin zeigt der der unterste Pfeil auf der rechten Seite? Sowohl zu Tätigkeits-, als auch Bedürfnismuster? Oder auf die gesamte rechte Spalte?

11

Im Prinzip auf die gesamte rechte Seite. Es geht darum, dass der rote Bubble zunächst immer Mittel über den Mittel-Hub anfragt. Anschließend „bespricht“ er dann die Details mit den einzelnen Datenbanken selbst.

1 „Gefällt mir“
12

Ist das okay so?

2020-06-16_Datenmodell_transcomm
2020-06-16_Datenmodell_transcomm3344×2392 405 KB

1 „Gefällt mir“
13

Toll, danke. Kannst du aus einem der UI2s noch UI1 machen? :slight_smile:

14

Ein Klassiker… :slight_smile:

Ist gemacht.