Re: [Ag Meinungsfindungstool] qKonsens, Probble, fundiert-entscheiden, d!sco und der Common Discussion Standard (CDS*)

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

Hi Frauke,

sorry - ich wollte dich nicht zensieren, sondern in bester Absicht die 
anderen Informieren und einbeziehen ohne alle Mails in eine verpacken zu 
müssen. Auch wollte ich nicht Deine Aussagen verfälschen.

Als ich die ganzen Antworten und Informationen las, dachte ich das könnte 
für andere hilfreich sein die Funktionalität in qprobble besser zu 
verstehen.

Cheers
Marc

-----Original Message----- 
From: Frauke Mattfeldt
Sent: Saturday, January 26, 2013 2:47 PM
To: marc
Cc: Piraten AG Meinungsfindungstool ; Wolfgang Schallehn
Subject: Re: qKonsens, Probble, fundiert-entscheiden, d!sco und der Common 
Discussion Standard (CDS*)

Hallo Marc,
wenn Du mein Geschreibsel schon ungefragt auf die Mailingliste setzt,
dann zensiere doch bitte nicht die entscheidenden Punkte, auf die ich
hinaus wollte, raus.
Die Sache mit den Workflows, Ontologie und so verstehe ich nicht, habe
ich auch noch nie verstanden. Mir muss man das immer in einfacher
verständlicher, am besten deutscher Sprache erklären, damit sich Bilder
dazu in meinem Kopf entwickeln. Mir ist das alles zu abstrakt. Sorry.


Am 26.01.2013 14:03, schrieb marc:
> Hi Frauke, Wolfgang und der ganze Rest,
>
> ich musste jetzt mal die Mailingliste mit ins Boot holen ;o)
> Es hatten sich zu viele interessante Informationen angesammelt. Ich hoffe
> das geht in Ordnung.
>
>
> HINWEIS: Auch wenn das jetzt eine ätzend lange E-Mail geworden ist, würde
> ich mich freuen, wenn wir über die einzelnen Punkte Einigkeit erzeugen
> könnten!
>
>
> Zur Info an die Mailingliste. Es geht um den qprobble-Test:
> http://www.karten-verlag.de/qprobble/
>
> Anmerkungen zu den Tests werden hier gesammelt:
> http://meinungsfindungstool.piratenpad.de/ProbbleAnregungen
>
>
> Frauke schrieb:
> > marc schrieb:
> > > @Frauke: Erstes Fazit: bisher saubere Umsetzung - Gratulation! Aber es
> > > gibt auch noch sehr sehr sehr viel in Richtung Usability und Ergonomie
> > > zu tun! Als wichtigsten FIX sehe ich die Möglichkeit zur Verknüpfung
> > > an. Ohne Verknüpfung kann glaube ich nicht wirklich Mehrwert 
> > > entstehen...
> > Ja. Das sehe ich ganz genau so. Du meinst die Verknüpfungsfunktion der
> > Kernaussagen? Da mache ich mich dann als nächstes dran!
>
> Genau. Aber eigentlich möchte ich jedes Element verknüpfen können. Es 
> müsste
> nur klar sein, welche Elemente miteinander in direkter und welche "nur" in
> indirekter Beziehung zueinander stehen können/dürfen.
>
>
> Frauke schrieb:
> > marc schrieb (im Pad):
> > > USABILITY: Es fällt mir schwer den Überblick zu bekommen! Und ich
> > > habe erst 1 Ist-Zustand, 1 Fragestellung, 1 These und 1 Kontraagrument.
> > >
> > > Lichtblick ist der Übersichtsgraph:
> > > http://www.karten-verlag.de/qprobble/question/structure/56/showGraph/
> > > Den Übersichtsgraph würde ich zum zentralen Orientierungspunkt machen.
> > > - bessere Visualisierung: im Graphen onHover Description einblenden
> > > - Direktes bearbeiten/bewerten der Elemente
> > > - Direktes neu hinzufügen von Elementen zu einzelnen Elementen im Graph
> > Zudem finde ich auch, dass es zu viel ist, wenn in der Suche die ganzen
> > Thesen, Ideen, IST-Zustände usw. angezeigt werden. Die Frage wäre, ob
> > man zusammenhängende Themenkomplexe irgendwie zusammen fassen und dann
> > zusammengefasst in der Suche auftauchen lassen könnte. Sonst wird es bei
> > zu vielen Themen (Thesen, Ideen, Fragestellungen) einfach zu viel. Oder
> > was meint ihr? Habt ihr da Ideen?
>
>
> Frauke schrieb:
> > marc schrieb:
> > > was hältst Du von der Idee, die Funktionalität nur Schrittweise für
> > > den Benutzer zur Verfügung zu stellen. Momentan ist das echt ein
> > > Expertentool - das versteht wahrscheinlich niemand fürchte ich.
> > >
> > > Vielleicht ist das was Du Stationen nennst genau das, was ich mit
> > > einzelnen Workflow Templates abbilden würde. Es gibt verschiedene
> > > 'Stationen' die ein Element im Workflow durchlaufen kann.
> >
> > Hallo Marc,
> > "Stationen" hatte ich deshalb geschrieben, weil Wolfgang und ich schon
> > mal drüber gesprochen hatten und er gesagt hat, dass das Wort "Element"
> > nicht passend sei. Wir kamen dann auf das Wort "Stationen".
> > Elemente (Stationen) sind bei mir:
> >
> > - IST-Zustand
> > - These
> > - Fragestellung
> > - Idee
> > - Konzept
> > - Projekt
> > - Petition
> > - Ziel
> >
> > Vorher gab's im probble ja nur IST-Zustände und Ideen, wobei auch die
> > Ideen sich auf einen IST-Zustand beziehen mussten. Letztendlich ging es
> > also immer nur von einem IST-Zustand aus.
> > Grundidee, es anders zu machen war, dass jemand vielleicht eine Idee
> > einstellen will - ohne dazu einen IST-Zustand einzustellen. So nach dem
> > Motto "Ich hab da ne tolle Idee". Jetzt kann man auch mit einer These,
> > einer Fragestellung usw. anfangen und die einzelnen Element miteinander
> > verknüpfen. So hatte ich mir das gedacht. D.h. man kann eine Idee
> > einstellen und die dann später mit einem oder mehreren IST-Zuständen
> > verknüpfen - oder man kann einen IST-Zustand mit mehreren Ideen, Thesen,
> > Zielen usw. verknüpfen. Letztendlich sind alle Elemente miteinander
> > verknüpfbar.
> > Ich finde es aber auch unübersichtlich so, wie es jetzt ist. Vor allem
> > nervt es, wenn alles in der Suche auftaucht. Das sieht man ja jetzt 
> > schon.
>
> Frauke schrieb:
> > marc schrieb:
> > > Das über die momentan Oberfläche zu ermitteln scheint mir fast
> > > aussichtslos. Ist es Dir möglich eine State Machine
> > > (http://en.wikipedia.org/wiki/UML_state_machine) für die aktuelle
> > > Implementierung zu erstellen? Ich denke das wäre auch für eine
> > > Diskussion über die Zusammenhänge und den Prozess hilfreich.
> > >
> > > Was meinst Du?
> >
> > Was ich meine ist, dass es ja eine Tool-Idee "Thesis" gab, dann die
> > Idee von Karsten, probble, qkonsens usw. -> aber wir haben keinen
> > gemeinsamen Prozess draus gemacht.
> > Außerdem gibt es wohl sonst niemanden, der das programmieren will
> > (zum Beispiel das Tool "thesis").
> > Erst dann macht aus meiner Sicht die Framework-Idee und auch der
> > ganze UML-Kram Sinn.
>
> Aber genau darum geht es doch, denke ich. Wir müssen einen für 
> Diskussionen
> übergreifenden Prozess definieren, aber eben auch inklusive der Daten und
> ihrer Bedeutung. Das ist für mich der von uns und allen Beteiligten und
> Interessierten zu definierende "Common Discussion Standard", von dem ich 
> an
> der einen oder anderen Stelle bereits sprach.
>
>
> Common Discussion Standard (CDS*) == Ontology + Workflows
>
>
> FRAMEWORK (CORE)
>
> d!sco Core ist der/die Prototyp/Referenzimplementierung für das Framework.
> Es besteht aus der Ontologie und einem Teil der Workflows, implementiert
> also den "Common Discussion Standard" nicht vollständig.
>
> Die Web API des d!sco Core Prototypen ermöglicht den Plug-Ins die 
> Teilnahme
> an den Core Workflows UND den Zugriff auf die gemeinsamen Daten, welche
> immer in Form und Bedeutung der Ontologie vorliegen.
>
>
> PLUG-INS
>
> Jedes MFT Tool, welches sich dem "Common Discussion Standard" anschließt 
> und
> somit CDS konform ist, wird d!sco Plug-In genannt. Die Plug-Ins müssen die
> d!sco Ontology und Teile der d!sco Workflows implementieren.
>
> d!sco Plug-Ins bilden in ihrer Implementierung in der Regel spezielle
> Diskussionsmethoden ab und können daher auch über den CDS hinaus eigene
> Daten und Workflows definieren.
>
>
> ONTOLOGY
>
> Mit der d!sco Ontology haben wir bereits angefangen einen Teil des CDS zu
> definieren. Die Ontologie definiert das gemeinsame Vokabular aller d!sco
> Plug-Ins und dient dem Datenaustausch.
>
>
> WORKFLOWS
>
> Jetzt müssen wir uns langsam an die Frage der Workflows heranwagen. Hier
> wird es mMn genauso Gemeinsamkeiten in den Prozessen geben, welche wir in
> die d!sco Workflows übernehmen können. Wahrscheinlich ist dies auch eher 
> ein
> globaler, zusammenführender Workflow, welcher die einzelne Stufen der
> Diskussion toolübergreifend verbinden kann.
>
> Dabei werden einige d!sco Workflows direct durch den d!sco Core
> bereitgestellt, während andere durch die d!sco Plug-Ins implementiert 
> werden
> müssen. Die d!sco Workflows teilen sich also in Core Workflows und Plug-In
> Workflows auf.
>
> Eine der vordringlichsten Fragen lautet mMn in welcher Form wir jetzt 
> diese
> d!sco Workflows definieren wollen.
>
>
> Cheers
> marc
>
>
> *  CDS meint hier NICHT "Credit Default Swap" ;o)