[Ag Meinungsfindungstool] Nächste Schritte in Richtung d!sco Spezifikation

["marc" <marc AT merkstduwas.de>]

Hi Jana + Liste,

ich habe gerade Zeit gefunden einmal in Ruhe die Abhandlung zum funktionalen
Faschismus zu lesen
(http://wiki.piratenpartei.de/Benutzer:Janonymous/FunktionalerFaschismus).
Hut ab! Finde ich sehr anschaulich beschrieben - allerdings habe ich im
ersten Drittel einiges nicht verstanden, da etwas zu akademisch für meinen
Geschmack.

Was mich als Softwareentwickler jetzt aber am brennendsten daran
interessiert ist, wo und wie wir das im Kontext d!sco konzeptionell
ansiedeln.

Für mich sieht der FF nach einer Filterfunktion aus. Basierend auf den
komplex zu erfassenden Diagnosedaten und der Ermittlung des globalen
ff-Wertes als Score, könnten durch dieses FF-Score-Filter-Modul
entsprechende Kandidaten im Diskurs identifiziert werden. Momentan habe ich
im Detail noch keine Vorstellung davon, wie die Datenerfassung erfolgen
könnte. Wahrscheinlich könnte es ein halbautomatisierter Prozess aus
Data-Mining und menschlicher Interaktion sein. Das hat dann schon irgendwie
etwas von Rasterfahndung ;o)

Aber ich denke, dass es auf jeden Fall diverse Filter-Module geben können
sollte, welche unterschiedlichste Filterlogik implementieren. Das
FF-Score-Filtermodul könnte vielleicht auch ein PoC Kanditat sein?

Meine Idee wäre es jetzt, zu versuchen den FF derart zu abstrahieren, dass
wir zu einem ersten Entwurf eines generischen Konzeptes für d!sco
Filter-Module - oder noch besser für d!sco Module allgemein - gelangen. Eine
radikale Abstraktion könnte dem EVA Prinzip folgen: Eingabe - Verarbeitung -
Ausgabe. Das ist natürlich sehr banal, da wirklich jede Form der
elektronischen Datenverarbeitung auf diesem grundlegenden Prinzip basiert.

Das ist aber genau was mMn auf einem hohen Abstraktionsniveau bei der
Diagnose des FF passiert: Die Diskussionsdaten (Eingabe) liefern die
Grundlage für die Funktionsanalyse (Verarbeitung), welche wiederum den
FF-Score liefert (Ausgabe).

Aus Sicht des System-Designs würde ich mich daher zunächst gerne auf diesem
hohen Abstraktionsgrad bewegen und grundsätzlich die Frage der
Modularisierung untersuchen. Z.B. glaube ich, dass wir Module anhand ihrer
Verarbeitungslogik weiter, z.B. in Filter und Aggregatoren, unterteilen
könnten.

Dann stellt sich mir die Frage nach dem Schema. Zum Einen betrachte ich
Module als funktional von d!sco unabhängige Softwarekomponenten, welche über
einheitliche Schnittstellen in den Gesamtprozess integriert werden können.
Zum Anderen brauchen wir für die Schnittstellendefinition eine
detailliertere Vorstellung von der generellen Funktionsweise der Module
innerhalb des Gesamtprozess.

Um eine bessere Vorstellung von den Modulen zu bekommen, könnten wir
vielleicht überlegen, welche generellen Eigenschaften diese haben sollten.
Z.B. "A call to a module MUST be idempotent" und "A module MUST be callable
at any time (within the workflow)". Btw., we should specify any requirement
for d!sco in english. First and foremost this might keep the specification
short ;o) But it will also help to receive attention from the international
community in the area of online deliberation tools.

Anyway, das sind jetzt alles erste, nur ganz grobe Gedanken, welche mir beim
Lesen der Abhandlung gekommen sind.

Quintessenz für mich ist, dass wir es schaffen müssen, uns auf einer
gemeinsamen Abstraktionsebene zu treffen! Und Abstraktion ist meiner Meinung
nach unerlässlich für die Verbindung von Theorie und Implementierung. Daher
wäre aus meiner Sicht eine noch grundlegendere Anforderung die Verständigung
auf folgende, sehr abstrakte Grundbegriffe, welche zur Spezifikation des
Diskussionssystems benötigt werden, zu erreichen. Wichtig hierbei ist zu
verstehen, dass es sich bei dem zu spezifizierenden Diskussionssystem nicht
um eine einzelne monolithische Implementierung, sondern um die Orchestration
unterschiedlichster Softwaresysteme handeln könnte:

- ONLINE DELIBERATION TOOL
  Softwaresystem, welches eine spezifische Theorie\Methode im Bereich der
Online-Partizipation implementiert; möglicher Kandidat für ein d!sco Modul,
wie z.B. WikiArguments, Findeco, Votorola usw.; Siehe auch
http://en.wikipedia.org/wiki/Online_deliberation

- DISCUSSION SYSTEM
  Selbstlernendes Softwaresystem, welches zentraler Gegenstand der
Betrachtung innerhalb der AG MFT ist und welches aus der Spezifikation
(d!sco) und dem evolutionären Wettbewerbsprozess der Module heraus entsteht
und weiterentwickelt wird; siehe auch
http://de.wikipedia.org/wiki/Software-System und System (2) im Gesamtkontext
http://wiki.piratenpartei.de/wiki/images/7/72/MFT_BigPicture_v01.jpg

  - D!SCO
    Akronym für die umfassende, konkrete Spezifikation eines strukturierten
Diskussionssystems auf der Basis einer Ontologie; alle mit "d!sco"
vorangestellten Begriffe, inkl. der Ontologie selbst, sind Gegenstand dieser
Spezifikation

- DISCUSSION DATA
  Daten, welche innerhalb des Diskussionssystems, entweder über manuelle
Eingabe oder maschinelle Verarbeitung, anfallen; siehe auch
http://de.wikipedia.org/wiki/Daten

- DISCUSSION ONTOLOGY
  gemeinsames Vokabular des Diskussionssystems und Basis aller Module;
maximale Ausprägung der Eigenschaften von Diskussionsdaten; siehe auch
http://de.wikipedia.org/wiki/Ontologie_%28Informatik%29

- D!SCO MODUL
  eine konkrete Implementierung einer Theorie/Methode durch d!sco
kompatibles Online Deliberation Tool oder d!sco PoC; ersetzt den Begriff
PLUG-IN; siehe auch http://de.wikipedia.org/wiki/Modul_%28Software%29

  - D!SCO FILTER (MODUL)
    ein Modul zur Begrenzung der Diskussionsdaten (ohne Persistenz); siehe
auch http://de.wikipedia.org/wiki/Pipes_und_Filter

  - D!SCO AGGREGATOR (MODUL)
    ein Modul zur Zusammenführung und/oder Veredelung von Diskussionsdaten,
z.B. durch unterschiedliche Konsensverfahren (mit Persistenz); siehe auch
http://de.wikipedia.org/wiki/Aggregator

- D!SCO WORKFLOW
  übergreifender Diskussions-/Willensbildungsprozess, welcher im
Diskussionssystem durch die Verbindung von Modulen orchestriert wird; siehe
auch http://de.wikipedia.org/wiki/Arbeitsablauf

  - D!SCO (WORKFLOW) TEMPLATE
    vorkonfigurierte Workflow Orchestration, welcher eine spezifische
Prozesstheorie/-methode abbildet; siehe auch
http://de.wikipedia.org/wiki/Template

- D!SCO FRAME(WORK)
  Sammlung von Softwarekomponenten, -bibliotheken, How-Tos und Best
Practices zur Vereinfachung der Implementierung und Einbindung eigener d!sco
Module; siehe auch http://de.wikipedia.org/wiki/Framework

- D!SCO POC IMPLEMENTATION
  Prototypische Implementierung zur Evaluierung einer spezifischen
Theorie/Methode

- tbc.

Und yes, the above definitions should be translated to english as soon as
they are fixed for the first iteration.

Müsste mal wieder ein Bildchen dazu malen, glaube ich...

Macht das trotzdem schon irgendwie Sinn?
Was meint Ihr?

Das ist natürlich auch ein herrliches Thema für unser kommendes dienstags
Mumble...

Cheers
Marc

---
“You felt it your entire life. That there’s something wrong with the
democracy. You don’t know what it is, but it’s there. Like a splinter in
your mind — driving you mad. It is this feeling that has brought you to AG
MFT. Do you know what I’m talking about?”