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

[janonymous2 <janonymous2 AT news.piratenpartei.de>]

Hallo Marc,

Marc schrieb:

> 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)

Der Text ist in stetigem Progress durch Beobachtung der Phänomene, die 
Interaktion mit Interessierten und auch mit Personen, die entsprechende 
Meme tragen. Von der Sprachlichkeit, klar, ist das noch ein Zwischending 
und sollte auch in Richtung Wissenschaftsjournalismus optimiert werden.

Andererseits ist das aber auch ein neues Forschungsprogramm, dass sich 
neben der Anbindung an die Forschung zur Korruption von 
Willensbildungsprozessen (PSI-Theorie) auch an bekannte Philosophen, wie 
Platon, Goethes Faust oder Habermas anknüpfen lässt. Die Herausforderung 
besteht aber nicht nur darin, den Gegenstand für andere verständlicher 
und zugänglich zu machen, sondern auch darin, Gegenstrategien gegen diese 
Formen geistiger Korruption und deren Risikofaktoren bzw. gegen die 
Mechanismen der psychologischen Aushebelung des Gewissens zu finden.

Die sehe ich u.a. in der Umgestaltung politischer Entscheidungsprozesse 
analog der menschlichen Willensbildung und in neuen, konfliktfreien 
Konsensverfahren: 
http://wiki.piratenpartei.de/Benutzer:Janonymous/Metatheorie_der_politischen_Willensbildung

Bei der geistigen Korruption handelt es sich einerseits um Verzerrungen im 
kollektiven Willensbildungsprozess, etwa wenn Personen gezwungen werden, 
all die Details und Möglichkeiten, die sie sehen und etwa hypothetische 
Wahrscheinlichkeitsmaße in ihrem Kopf auf ein Schwarz-Weiß-Schema 
runterbrechen müssen, ein Prozess bei dem unheimlich viel Information 
verloren geht und unbewusst manipulaiert und korrumpiert wird, wenn man 
hier nicht im Vorfeld versucht, diese Musterbildungprozesse unverfälscht 
zu skalieren.

Man kann sich die Skalierung von freien Musterbildungsprozessen auch 
vorstellen als ein zwangloses, realitätsgetreues Abbilden der Meinung 
einer Person. Die Meinungen vieler Personen zu einem Sachverhalt werden 
dann gemittelt und erst dadurch ergeben sich Rangfolgen und kollektive 
Prioritäten. Zwingt man eine Person bzgl. ihrer geistigen Prozesse in 
eine Informationsreduktion, liegt genau hier das manipulative Moment. 
Triggert man gleichzeitig noch an Lebensstilkategorien und 
Mangelbedürfnissen angelehnt, entsprechend diversiviziert oberflächliche 
Informationsverarbeitung zum Meinungsobjekt an (bspw. über 
Kontrasteffekte, Feindbilder, Stereotypen, Expertenstatus, Wiederholung), 
kann man so Massen kontrollieren. vgl. auch Kombi von "Wollt ihr den 
totalen Krieg" ja/nein kombiniert mit entsprechender Propaganda.

Man kann also durchaus (psycho-) logische Herleitungen machen, inwiefern 
Diskussions- und Messprozesse korrumpiert und verfälscht werden können. 
Dahinter steht eine ganz einfache Logik, die für ein möglichst 
unkorrumpiertes Konvergenz- oder Konsensverfahren eine natürliche 
Hierarchie in der Skalierung vorsieht, von Fuzzy Logic und Graustufen 
(metrische Skalierung) hin zu Rangfolge (Ordinalskala) und Schwarz-Weiß 
(Nominalskala, Binärlogik). Oder zum Beispiel die offene bottom 
up-Version von offenen zu geschlossenen Fragen.

Anhand dieser Erkenntnisse, was natürliche, unverfälschte 
Meinungsbildungsprozesse brauchen und zu den Mechanismen der Korrumpierung 
der Meinungs- und Willensbildung, sind also einerseits die 
Weiterentwicklung von Strukturen und Entscheidungsverfahren angezeigt, die 
eine entsprechende unkorrumpierte und transparente Willensbildung zulassen.

Andererseits unterliegt das Phänomen des funktionalen Faschismus als 
abstrakter Kern bzw. Maß der geistigen Korrumpierung, einer Art 
unterbewussten Fortplanzung mit entsprechenden Mechanismen, die das 
Gewissen einer Person aushebeln, die man durch Training und ein auf 
Selbststeuerung (statt auf fremdsteuerung) getrimmtes System abmildern 
kann.

> 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?

Hierbei könnte sich tatsächlich auch ein zusätzliches Filtermodul 
eignen. Dieses wäre in meinen Augen aber auch wieder eine Art 
selbstlernendes System, dass erst durch die Beteiligung anderer und die 
Weiterentwicklung der Mustererkennung zunehmend wirksam werden kann. 
Wichtig hierbei ist, dass sich funktionaler Faschismus nicht auf Personen, 
sondern menschenunwürdige Verhaltensweisen und politische Strukturen 
bezieht.

> 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.

Das können wir gern mal probieren. Schätze aber, dass das Schema etwas 
komplexer sein muss, weil man in diesem Modul auch wieder Mess- und 
Rückkopplungsprozesse braucht und der user an der Weiterentwicklung 
beteiligt wird im Bestfall.

> 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...

Denke, dass ist eine gute Basis. :o)

Gruß,
Jano