.Ontologie-Verständnis

Teilnehmende User (damit man sie ihrer Farbe zuordnen kann; anonym auch OK)

• bloxx
• Merkbefreiter
• flow
• DerThomas
• moonopool
• /
• ntroPi
• Wolfgang
• arndot
  
  

Puh, fast 500 Zeilen - aber immer noch weniger als das auf der Mailingliste wäre... Und deutlich schneller...+1


Hinweis/Frage: Vielleicht wäre es hilfreich, wenn Gegenstimmen, also -1, durch einen kurzen Satz (KA) ausgeführt würden? (konstruktive Kritik)

• +1: Ja, meist schon bzw. Zustimmung für einen solchen Satz von jemand anderem signalisieren, damit der Autor weiß, was nicht stimmt.
  
  
  
  

I) Breiter Konsens (Aussagen, die von allen (mindestens 4) Bewertern gebilligt werden. Muss ständig angepasst werden.)

• Bitte auch schauen, ob ihr hier Einspruch erhebt. Den aber bitte unten in der KA-Liste posten zwecks Zusammenführung.
  
  
• [KA8] Es wird zwangsläufig Daten geben, die für manche Plattformen unbrauchbar sind.
• Wir wollen alle, dass d!sco später ein P2P-Netzwerk wird.
• Das P2P Netzwerk ermöglicht zwar den Datenaustausch zwischen allen Tools, dabei werden aber nicht zwingend alle Daten synchronisiert. ==> Detailfragen vertagt!
• Es wird ein Basis-PoC für ein herkömmliches Tool erstellt, das vorsichtig überprüft, welche Auswirkungen z.B. eine Mailingliste hätte.
  
  

Was wir von d!sco denken, ist:

• P2P-Netzwerk (Vorschlag: "d!sco P2P")
• Webseite für mehrere Tools, die unter einer Oberfläche erscheinen (Vorschlag: "d!sco Portal")
• zentrale (geteilte?) Datenbasis (Eine pro d!sco Portal möglich) (Vorschlag: "d!sco Database")
• gemeinsame Sprache (Vorschlag: "d!sco Ontology")

Was ist d!sco wirklich? - gesamtes System(-Konzept), das die Punkte enthält !!+1+1+1

1) Kernaussagen plus Bewertung (-1 oder +1 anhängen)

• Nötige Definitionen:
  • Plug-in = Diskussionssystem das in d!sco eingebunden ist und sich alle Daten mit den anderen Plugins teilt. Sofortiges Umschalten zwischen Plug-Ins ist möglich.
  • Tool = Diskussionssystem, das nicht voll integriert ist und dementsrechend abweichende Daten nutzen kann.
    • Nutzt das Tool die gleiche Datenbasis?
      • Das ist Kern des Arguments vermute ich. Ich würde sagen: Ja aber nur lesend, außer wenn ein d!sco admin die zentrale Datenbank so einstellt, dass von diesem Tool explizit (alle oder gefilterte) Daten übernommen werden.
        
        
        
        

Also:
Was wir von d!sco denken, ist:

• P2P-Netzwerk (Vorschlag: "d!sco P2P")
• Webseite für mehrere Tools, die unter einer Oberfläche erscheinen (Vorschlag: "d!sco Portal")
• zentrale (geteilte?) Datenbasis (Eine pro d!sco Portal möglich) (Vorschlag: "d!sco Database")
• gemeinsame Sprache (Vorschlag: "d!sco Ontology")

Was ist d!sco wirklich? - gesamtes System(-Konzept), das die Punkte enthält !!+1+1+1

http://wiki.piratenpartei.de/wiki/images/3/37/DiscussionSystem-Overview.jpg

• [KA1] Es ist machbar, dass Plug-ins für sie semantisch zu ungenaue Inhalte herausfiltern.
  • unbedeutend geworden+1+1+1
  • +1+1+1
  • -1-1
    • Um solche Inhalte zu filtern, müßten Filter-Kriterien gefunden werden, die etwas taugen. Der Name eines Tools als Ausschluß taugt schon mal nicht, weil es in Zukunft ja neue Foren-Tools geben könnte, die unstrukturierte Inhalte posten. ++1
  • +-0, das bürdet den Plugins viel zusätzliche Arbeit auf. Die meisten Plugins werden strukturierte Diskussionen unerschiedlich abbilden wollen und unstrukturierte Infos ignorieren -> man lässt sie besser gleich weg. Andererseits wird es immer Plugins geben die schlecht/gar nicht/anders strukturieren. Eine Filterung ist auf lange Sicht also unumgänglich.+1
    • empfinde ich als guten Kompromiss - also hohe Priorität auf einfache Filtermöglichkeiten für die Plugins?+1
  • +-0 Das geht nur dann, wenn alle integrierten Diskussionssysteme den Inhalt blocken; wenn nur ein einziges durchschaltet, spült es die Inhalte in den Kreislauf der Diskussionssysteme rein, die von den anderen integrierten Diskussionssystemen unerwünscht sind
    • Auch das integrierende Diskussionssystem kann dazu beitragen die 'Qualität'  der importierten Daten zu erhöhen. Das ist das Ziel. Tut es das nicht, sondern leitet die qualitativ niederwertigen Diskussionsdaten einfach  nur durch, dann wird es bald auch einen Filter der anderen Tools auf das  'einschleusende' Tool geben.+1
    • Klar, das passiert auch informell - beispielsweise spontanes Copy & paste  aus seinen eigenen E-Mails und Tweets raus - das gehört aber nicht strukturell auch noch gefördert
    • Ein "Durchspülen" schlechter Daten kann im Normalfall nicht vorkommen:
      • Wenn das Problem der unstrukturierten Daten in fehlender Struktur (= Semantik) liegt, dann wird das Problem doch durch Hinzufügen dieser Semantik gelöst.
        • Verschiedene Plugins benötigen unterschiedlich viel von der Semantik.
          • Ja. Jedes System nutzt die Inhalte, die seinen Semantikstandards entsprechen. Das verstehe ich unter "Filtern".
            • Inklusive Datenquelle siehe [KA1a]
        • Einzelne "Posts" ohne weitere Zusammenhänge sind korrekt definierte Elemente. Leider völlig strukturlos in der Masse.
          • Es gibt Systeme, denen solche Posts reichen, und solche, denen sie nicht reichen. In Systemen mit niedriger Semantikschwelle lassen sich Semantikerweiterungsfunktionen einbauen.+1
      • Ein System, das regelmäßig falsche Semantik einbaut, erfüllt nicht die Anforderungen an d!sco, weil es Falschinformationen einspeist.+1
      • Dagegen erfüllt mMn ein System, das keine Semantik anfügt, sehr wohl die Anforderungen, weil diese fehlende Semantik unproblematisch herausgefiltert werden kann.+1
    • Die Qualität eines Beitrags kann man nicht auf Semantik/Struktur runterbrechen; je nach Kontext kann ein Beitrag sehr rhetorisch, polemisch, off-topic, etc. geprägt sein - dazu nehme man beispielsweise einfach mal einige Beiträge aus einer Mailingliste. Würde so ein Inhalt automatisiert in die Daten-Basis eingespeist werden und über eines der Plug-Ins sichtbar sein, würde er damit die Gesamt-Diskussion in d!sco prägen; selbst dann, wenn von allen Plug-Ins nur eines den Inhalt verwendet - man schaltet nämlich bei der Diskussion gerne mal durch alle Plug-Ins durch, und wenn man über eine Darstellungsart der Diskussion dann 'nen rotzig-destruktiven Beitrag sieht, dann prägt das sein Empfinden der Diskussion und infolge dessen seinen folgenden Input in die Diskussion.+1
      • Gerade vor dem Hintergrund ist ein manuelles Übertragen der Inhalte unerlässlich - das kann man nicht automatisieren; wenn man allerdings aus qualitativen Gründen den Nutzer den Übertrag in's Diskussionssystem überlässt, stellt sich die Frage nach dem Mehrwert eines Andock-Elements im Verhältnis zu Copy & Paste. Dazu weiter unten mehr...
        • Generell ja, aber wenn es mehrere Plattformen mit hohem Qualitätsanspruch gibt können diese von einem automatischen Austausch untereinander profitieren. In diesem Szenario wäre Copy&Paste deutlich schwächer.
      • Plugins können im Verbund nicht filtern;?? wenn sie wirklich knallhart am Vorhaben festhalten,  wirksam zu filtern, dürfen sie keinen Verbund eingehen, der auch  ML/Forum/newsgroup implementiert. Das ist aber nicht Sinn der Sache; wir wollen ja gerade zusammenführen+1, und nicht zersplittert lassen; wenn das einfacher geht, wenn man sich von ML/Forum/newsgroup-Implementierung  distanziert, sollte man das machen+1
        
        
• [KA1a] Plugins können filtern [KA1], benötigen aber die Möglichkeit selbst zu bestimmen von welchen Plattformen sie überhaupt Daten erhalten. Optimalerweise bieten die Plattform vorgefilterte Ergebnisse nach verschiedenen Kriterien an.
  • erledigt.+1
  • Solange d!sco mit zentralem Server läuft sollte dieser eine Vorfilterung nach Datenquelle anbieten.
    • Versteh ich nicht ganz...
      • Na wenn jetzt die Mailingliste in die Datenbank gekippt wird z.B.
      • Ach so, ich weiß was du meinst. Wäre für mich OK.
  • +1+1+1
  • -1
    
    
• [KA1b] (laxere Version von KA1a - um die Zustimmung auszutesten) Nach der Einführung der P2P-Variante sollte es keine Probleme mehr mit unstrukturierten Plugins geben, wenn jedes Plugin seine Daten selbst speichert und für andere Plugins je nach deren Bedürfnissen diese filtert (Filterprotokoll für Abfragen) und jedes Plugin Anfragen an alle Server schickt, von denen es Inhalte abrufen will. So könnte jedes Plugin selbst entscheiden, was es anzeigen will.
  • enthält technische Details, die wir vertagen+1+1+1+1+1+1
    • z.B. SPARQL oder OData sind Teil der d!sco Spezifikation für die Filterung, aber zu simpel und schlicht (Post-Länge?)
  • Begründung: Letztendlich kann man keiner Plattform eine andere aufdrängen. Andererseits ist es auch unsinnig, eine Plattform einer anderen vorzuenthalten. Eine möglichst liberale und offene Lösung wie diese ist daher optimal.+1
  • Diskussionsgrundlage (bloxx, ntroPi): https://meinungsfindungstool.piratenpad.de/disk1
  • +1+1
  • -1
    
    
• [KA2] Aus [KA1] folgt, dass, abgesehen von einer eventuellen Serverlast, nichts gegen eine Integration von herkömmlichen Plattformen wie Foren spricht.
  • abgehakt+1
  • es spricht unter Annahme von KA1a/b nichts dagegen, dass das jemand freiwillig zusätzlich tut. Es spricht der Aufwand dagegen es jetzt schon als AG Ziel zu definieren.
  • +1+1+1+1+1
  • +1, Stichworte Whitelist, Blacklist
  • -1-1-1
    • seid ihr auch gegen diese Aussage, angenommen, [KA1] wäre richtig? (So war das nämlich gemeint.) Was steht dann noch im Weg?
      • -1, ja auch wenn [KA1] gilt. Unstrukturierte Diskussionen sollten im System nicht nutzlos herumliegen. Etwas anderes wäre es wenn es einen systematischen Prozess gibt der diese nachträglich mit Struktur anreichert und zwar so, dass auch alle plugins etwas davon haben.
        • Manche Plattformen akzeptieren auch unstrukturierte Daten (wie multilectics) und ermöglichen die Anreicherung.+1
        • Wobei es ja nicht unbedingt gegen die Integration solcher Diskussionen spricht, wenn sie nutzlos herumliegen. Das ist eben ungenutztes Potenzial, aber kein Nachteil.
          • Auf lange Sicht geb ich dir da Recht. In der Anfangsphase ist es bremsender Ballast.
            
            
• [KA3] Wir müssen uns schon jetzt ernsthaft Gedanken über die Serverlast machen.
  • abgehakt
  • -1, denn für eine weitere Ausbaustufe ist die Idee ein P2P Netzwerk, zwischen allen beteiligten d!sco Instanzen, aufzubauen angedacht.+1
  • -1, Serverlast ist ein Problem das wir gerne hätten. [KA20] wäre hier evtl. eine Lösung die bestehende Bedenken zerstreuen kann.
  • -1-1
  • +1+1
  • -+ 0 Kann ich als Nicht-Tekkie nicht beurteilen
    
    
• [KA4] Der Ausschluss herkömmlicher Plattformen käme der Zensur gleich.
  • -1 abgehakt
  • -1 -1-1-1-1-1(stattdessen KA4/2)
  • -1, die Informationen sind auf den anderen Plattformen nach wie vor verfügbar. Verlinkung wo passend ist bereits vorgesehen. Zensur ist hier nicht passend, da nur strukturell und nicht Inhaltlich gefiltert würde. (Niemand spricht von Zensur, weil in der Zeitung keine Videos sind)
  • -1 Man kann diesen Standpunkt auch nicht als Zensur bezeichnen, weil hier nicht Meinungsfreiheit beschränkt wird, sondern sich auf einen gewissen Typus von  Kommunikationsmitteln beschränkt wird
    
    
• [KA4/2] (Alternative zu KA4) Der technische Ausschluss herkömmlicher Plattformen würde d!sco zu einem geschlossenen "App Store"-Ebenbild machen, das nur ausgewählten Tools den Zugriff erlaubt.
  • Ausschluss im "Körbchen" evtl. okay/sinnvoll, im P2P stimmt KA4/2
  • +1
  • Meinungen?
  • -1, Manche Datenquellen werden sich als zu groß und unstrukturiert herausstellen um in eine zentrale Datenbank übernommen werden zu können. Eine Ausschlussmöglichkeit muss es geben. Siehe KA11, KA20 zu Möglichkeiten dies fair und transparent zu schaffen. Wir können und wollen kein Twitter Mirror sein.
    • Ich meinte nicht, dass Filter verhindert werden. Mit technisch wollte ich ausdrücken, dass man ihnen den Zugriff (v.a. Schreibzugriff) auf d!sco untersagt.
      • Es muss die Möglichkeit durch die d!sco Betreiber geben Plattformen nach Bedarf vom Schreibzugriff auf d!sco auszuschließen.
        • Bei P2P und Open Source geht das mMn nicht. Das Filtern wird wirklich das A und O sein.
          • Auch bei einer per P2P verteilten "zentral verwalteten" Datenbank wäre das durch kryptographische Methoden möglich.
          • Ist eine Datenbank in die jeder alles schreiben kann wirklich noch etwas wert? Aber vllt. missverstehe ich dich hier. Wenn jedes Plugin seine eigenen Daten hält und diese nach Bedarf per P2P nur an die Plugins verteilt werden die überhaupt Daten von diesem Plugin haben wollen stellt das schreiben (in die eigene Datenbank) natürlich keine Gefahr fürs Gesamtsystem dar, da dass ja niemand verarbeiten muss der es nicht will.
  • -1 (bei Körbchen), aber +1 (bei Netzwerk) Plug-In-Selektion geschieht ja nicht nach kommerziellen Gesichtspunkten sondern einzig nach der Frage, ob der Kandidat ein Diskussionssystem ist oder nicht. Es ist ein sachlich vollkommen legitimes, schlüssiges Interesse, dass in ein Meta-Diskussionssystem auch nur Diskussionssysteme eingebunden werden. Datenabzug von außen ist zudem stets erlaubt und möglich.+1+1
    
    
• [KA4a] Es gibt genug herkömmliche Foren - deshalb kann von einem Ausschluß und Zensur keine Rede sein.
  • erledigt (keine Kernaussage)
  • -1-1, denn es geht um die gemeinsame Datenbasis und die Möglichkeit der Teilnahme der Plattformen an d!sco. Für mich müsste es schon sehr gute und wohlüberlegte Gründe geben, um einzelne Tools/Plug-Ins von d!sco auszuschließen. Dafür würden wir mMn aber zuerst einen Kriterien Katalog benötigen, um einzelne Diskussionsmethoden und ihre Implementierungen bewerten zu können.
  • Natürlich werden Herkömmliche von d!sco ausgeschlossen. Antrag auf Entfernung des Wortes "Ausschluss" aus KA4a.
  • +1, d!sco bietet eine Basis für strukturierte Disskusion. Jedes Plugin kann diese Struktur lesend nutzen. Unstrukturierte Nutzung lässt sich nicht verbieten wird jedoch explizit nicht empfohlen und vermutlich von den meisten Plugins ausgefiltert.+1
    • genau meine Meinung! Ist aber kein Argument für KA4a, denn da geht es darum, dass Herkömmliche nicht in d!sco integriert werden (und die Struktur eben nicht nutzen können), oder?
      • Sie können sie nicht schreibend nutzen, weil sie ihre Inhalte nicht ausreichend strukturieren. Das ist noch lange keine Zensur. Insbesondere bezieht sich Zensur normalerweise auf Inhalte statt auf Struktur.
      • Reden wir von einem technischen Ausschluss oder einem faktischen ("Filter-")Ausschluss?
      • Die Plugins werden eh Filtern wie wild, und das wird auch nötig sein weil schlechte Struktur nicht technich ausschließbar ist sondern nur über Konventionen und Moderatoren.
      • ...bzw. Filtern durch die Plattformen. Was ich eben nicht will, ist ein technischer Ausschluss (die Plattform darf nicht auf d!sco zugreifen).
      • Nein ich meine Filtern bei der Anzeige auf Pluginseite. Auf der Plattform sollte nur rechtlich problematisches gelöscht werden und sonst nix.+1+1
  • -1 halt' ich für kein legitimes Argument
    
    
• [KA4b] Herkömmliche Foren muß man nicht dringend selbst anbieten. Man kann sie verlinken und Möglichkeiten schaffen, von dort relevante Stichpunkte zu importieren.
  • abgehakt, P2P-Freiwilligen-Lösung auch okay
  • -1, denn es geht mMn nicht darum  neue Foren oder Mailinglisten zu entwickeln, sondern Andockstellen zu bestehenden Systemen anzubieten. Dies könnte durch Erweiterungen der zugrundeliegenden Foren- oder Mailinglisten-Software erfolgen. Die Foren- bzw- Mailinglistenbetreiber können dann entscheiden, ob sie die  Anbindungserweiterungsmodule für d!sco installieren wollen, oder nicht. Für die Nutzer der entsprechenden Tools ändert sich dadurch erst einmal nichts.+1+1
  • -1
  • +1, den bestehenden Foren kann ein Interface angeboten werden [KA10]&[KA10a], Repräsentation in einer zentralen Datenbank ist kein Grundrecht.
    • Interface ist noch recht schwammig definiert. Ich dachte da an mehr serverseitige Funktionen, z.B. mehr Filtermöglichkeiten.
    • Es geht auch nicht um Grundrechte. So wie du repräsentiert werden willst, will das ein Forenbetreiber vielleicht auch.
      • Wenn es irgendwelche Gründe gibt seine Inhalte nicht in die zentrale d!sco Datenbank zu übernehmen hat er halt Pech. Bleibt ihm die direkte Kommunikation mit einzelnen Plugins [KA1a/b].
  • -1 Verlinkung langt, ja; Inhalte-Import relevanter Stichpunkte kann imho nur manuell gescheit erfolgen und in keinster Weise nennenswert strukturell unterstützt werden; ich lass' mich da aber auch gerne vom Gegenteil überzeugen
    
    
• [KA5] Wir sind in der Proof-of-Concept-Phase und daher können wir durch die versuchsweise Einbindung herkömmlicher Plattformen nichts verlieren.
  • Beschluss Variante 1: Herkömmliche Plattformen werden erst angegangen wenn P2P Netzwerk verfügbar ist. +1+1
  • Beschluss Variante 2: Eine einzelne Herkömmliche Plattform wird schon in der Konzetphase eingebunden. Test Mailingliste oder AG Mailingliste um die Datenmenge zu beschränken. =0+1=0+1+1+1
  • 
    
  • +1+1+1+1+1
  • -1, da die proof of Concept im Katzenkörbchen ist aktuell.
  • -1
  • -1, doch eine Menge Zeit. Die unstrukturierten Diskussionen auf den herkömmlichen Plattformen sind eine schwache Datenbasis und zum Testen von Plugins denkbar schlecht geeignet. Hier lieber erst auf 1-2 vielversprechende Plugins konzentrieren.
    • Die PoCs sind doch eben zum Testen des Austauschs zw. Plugins gedacht. Da ist es denkbar ungeeignet, nur 1-2 PoCs zu verwenden.
      • Lieber 2 fertige als 6 unfertige.+1
  • -1 (bei Körbchen) aber +1 (bei Netzwerk) Das hängt davon ab, was man mit dem PoC macht; wenn er nur für uns ist, hätte ich diese Aussage bejaht; da jedoch davon auszugehen ist, dass mit dem PoC auch andere Leute aufgesucht werden, haben wir durch versuchsweise Einbindung herkömmlicher Plattformen sehr wohl was zu verlieren
    
    
• [KA5a] Durch Schaffung von herkömmlichen Foren als Plugin verlieren wir Nutzer und Programmierer, die sich beim Thema Kommunikation einen harten Bruch erwarten und dabei bitter enttäuscht werden.
  • erledigt
  • -1-1, siehe Kommentar zu KA4b. Der 'hart Bruch' kann weiterhin durch die Diskussionsmethoden der einzelnen Tools/Plug-Ins realisiert werden. Jedes Tool/Plug-In entscheidet dabei selbst, welche Daten es übernimmt.
    • +1
    • +1, ja sowohl der Bruch als auch die unstrukturierten Diskussionen sind unvermeidlich. Entscheidung durch die einzelnen Tools ist wichtig.
  • +1, ja da ein klares Ziel erfolgversprechender aussieht als eine eilerlegende Wollmilchsau, aber da müssen wir halt besser erklären, dass wir in erster Linie ein Interface/Protokoll entwickeln.
  • +1 (bei Körbchen) aber -1 bei (Netzwerk)
  • Bezieht sich [KA5a] auch auf [KA1]?
    
    
• [KA5b] Mindestbedingung bei Integration herkömmlicher Foren ist die, daß es sehr wirksame Methoden geben muß, damit kein Geschwafel in der Datenbank landet (Zeichenbegrenzung, Post-Frequenz-Begrenzung, damit sich die Leute auf das Wichtigste konzentrieren und kein Geschwafel herauskommt, Voting, ...), ansonsten torpedieren wir unsere Idee, daß wir die Kommunikation eine Stufe höher heben wollen.
  • in unserem Kontext erledigt
  • +9000 ;)
    • übrigens: genau solche Spaßvögel werden dann auf einer höheren Diskussionsebene einfach rausgefiltert ;o)
  • -9001, denn zum einen gibt es für jedes Tool/Plug-In die Möglichkeit die Diskussionsdaten zu filtern, zum anderen ist dies die zentralistische Sicht, welche mMn durch das P2P Netzwerk nicht mehr existiert.+1
  • -1
  • -1, Unrealistisch. Es wird immer rogue Plugins geben die sich nicht an Regeln halten. Manche Plugins werden solche Datenmengen sehen wollen, andere nicht.
  • -1 das ist zu wenig; Postqualität ist nicht nur Semantik/Struktur
    
    
• [KA5c] Die Integration herkömmlicher Foren birgt die Gefahr durch die Zentralität der Kommunikationsinfrastruktur, daß das Chaos, was jetzt noch auf tausenden großen Foren dezentral erzeugt wird, bald auf unserem Server gebündelt und mit viel mehr Traffic passieren wird. (Lawinen-Effekt wie bei anderen Tools vorher schon, die dann nicht darauf vorbereitet sind)
  • technisch - vertagt
  • -1, denn mMn haben wir d!sco bereits mit Hinblick auf ein P2P Netzwerk, also maximale Skalierung und Dezentralität, angedacht. Das wir mit einer zentralen Instanz im PoC starten ist einfach den pragmatischen Anfängen geschuldet. Gleich mit einem P2P Ansatz zu starten wäre ungleich aufwendiger und komplexer.+1
    • Und im Moment haben wir noch nicht mit den Datenmengen zu kämpfen. Im Gegenteil, der Server schläft dauernd ein und muss erst "aufgeweckt" werden...
  • +1, eine Vorauswahl der Quellen [durch das jeweilige Plugin] ist unbedingt nötig unabhängig von der Diskussion Strukturiert vs. Unstrukturiert. Alles ziellos ins System zu saugen hat keinen Nutzen.++1
    • In der Ontologie gibt es doch Strukturen, die so eingehalten werden müssen. Als "User" sollte man nur eintragen, was wirklich ein User ist. Ein Verstoß entspricht Spammen und/oder unangemessenem Verhalten. In so einem Fall muss man erwägen, die Plattform zu blacklisten. Aber herkömmliche Plattformen können sich sehr gut in die jetzige Ontologie integrieren.
      • Um beim Beispiel zu bleiben: Es kann ein Plugin/Tool geben das keine User hat. Genauso sind alle anderen Daten nicht für jedes Plugin interessant. Siehe Filter in [KA11]
      • Manche Felder werden sicher nicht von jedem gleich gefüllt. Was für den einen ein Topic ist, ist für den anderen nur eine weitere Kernaussage. Keine der Sichtweisen ist falsch und blacklistwürdig, dennoch kann das eine Plugin die "falschen" Daten von jenem anderen Plugin halt nicht problemlos nutzen. -> Opt-In für Datenquellen.
  • +- 0 Kann ich als Nicht-Tekkie nicht abschätzen
    
    
• [KA5d] Es gibt keine Belege oder Hinweise dafür, daß Nutzer eines herkömmlichen Forums ihr eigenes Forum nur wegen der Gründung eines neuen Forums verlassen und wechseln werden.
  • irrelevant
  • -1, siehe Kommentar zu KA4b.
  • -1, siehe KA5. Wir sollten es ausprobieren, und dann sehen wir ob es Probleme gibt.+1
  • +1, eine gewisse Treue ist da zweifellos vorhanden. Es muss aber auch gar nicht unser Ziel sein andere Foren zu ersetzen. Ein Plugin/Tool das zusätzlich zum Forum genutzt wird wenn eine einzelne Diskussion zu unübersichtlich wird hat auch seinen Wert.
  • -1 Ist zahlreich aus Unzufriedenheit heraus passiert; ich glaub' jedoch nicht, dass ein User sich jemals denken wird "Das Forum X ist mir zu doof, weil es nicht d!sco unterstützt; deshalb wechsle ich zu Forum Y, das d!sco unterstützt !" (Interessanter Aspekt!! Vielleicht doch?!)Wer annähernd so drauf ist, diskutiert eh nicht mehr in einem Forum und stellt sich in Foren als d!sco-Link-Schleuder auf.+1
    
    
• [KA5e] ... und wenn sie bei uns tatsächlich in einem herkömmlichen Forum-Plugin mitmachen, werden sie dann auch in ein "disziplinierteres" Diskussionssystem wechseln? - eher unwahrscheinlich (Wenn man einem Junkie die Wahl zwischen einem Keks und einem Joint gibt, wird er freiwillig den Keks essen, weil er den schwereren Weg, der eigentlich für ihn besser wäre, einschlagen möchte ?)
  • Marketingfrage - Klärung durch PoC+1+1
  • -1, siehe Kommentar zu KA5d
  • -1, würden sie überhaupt zu d!sco wechseln? Dafür gibt es auch keine Belege.
  • Ein Forum in d!sco ist eine Ausstiegsdroge.+1
  • -1, eine Migration ganzer Forensysteme ist unrealistisch. Sogar innerhalb der Piratenpartei. Auch mit d!sco ist eine AG gut beraten sich auf ein Referenz-Plugin für die Diskussionen zu einigen.
  • -1 Hierdurch wären sie ja näher dran, die Vorzüge eines Diskussionssystems kennen zu lernen und DAS macht Lust auf mehr.
    
    
• [KA5f] Es gibt keinen Benefit, aber eine Menge Risiken bei der Integration eines herkömmlichen Forums.
  • erledigt, irrelevant
  • -1, denn der Benefit ist bereits in mehreren KAs dargelegt.
    • z.B., dass mehr Leute auf d!sco umsteigen und später auf anderen Plattformen weiterdiskutieren.+1
    • z.B., dass multilectics sehr gute Kompatibilität mit dem Input von Foren hat.+1
  • -1, zumindest falls KA1 zutrifft.+1
  • -1, es gibt durchaus Benefit. Risiken sind Datenmüll und Zeitaufwand. Beides handhabbar nur sollten wir vorsichtig sein jetzt schon großen Aufwand zu betreiben.
  • +1 (bei Körbchen) aber -1 bei (Netzwerk)
    
    
• [KA5g] Benutzer "disziplinierterer" Diskussionssysteme könnten massenweise abspringen, wenn sie durch die Flut anderer Diskussionssysteme beeinträchtigt werden. Das wird zwangsläufig nicht ausbleiben.
  • geklärt
  • -1-1-1, denn das ist mMn eine Frage der Filterung. Es wird immer Tools/Plug-Ins geben, die mehr 'Inhalt' produzieren als andere. Hier gilt es entsprechende Mechanismen zu  entwickeln. Am besten testen wir das vorher an Extremen als PoC Implementierungen aus.+1+1
  • +1 (bei Körbchen) aber -1 bei (Netzwerk) Ich hab' den Eindruck, dass die Fragestellung nicht genau das erfasst, was gemeint ist; ich nehm' sie mal wortwörtlich. Diskusionssystem ist Diskussionssystem; ich seh' kein Problem mit großem Output aus anderen Diskussionssystemen. Die Interaktion durch das "Nebenher der Diskussionssysteme" im Rahmen von d!sco ist qualitativ unkritisch und was bloße Datenteilung angeht kann man semantisch filtern und auch da seh' ich ansonsten qualitativ keine Probleme.+1
    
    
    
    
• [KA5h] Da Foren eine gewisse Präsenz haben, besteht die Gefahr, daß kleinere Projekte, in denen sich die Qualität der Kommunikation durch ein neues Tool deutlich hebt, kaum sichtbar sind und ein Schatten-Dasein fristen.
  • Marketingfrage
  • mMn entspricht KA5h KA5e. Zusammenführen?-1-1
  • -1-1, siehe Kommentar zu KA5g+1+1
  • -1 die neuen Plattformen scheitern dann wenigstens nicht am Netzwerk-Effekt. Bei Ausschluss der Klassiker würde die gesamte d!sco-Plattform einen User-Mangel haben.+1-1
  • +1 (bei Körbchen) aber -1 bei (Netzwerk) Also, einen gewissen Hang zu altbewährtem zu greifen, wenn es denn Teil des Büffets ist, würd' ich nicht ausschließen; ja, mehr noch, kann ich mir sogar durchaus vorstellen
    
    
• [KA6] Die Einbindung herkömml. Plattformen könnte für einen Vertrauensverlust sorgen.
  • im Kontext erledigt
  • -1, denn genau das Gegenteil könnte der Fall sein, dass das Ausgrenzen von Tools/Plug-Ins zu Vorwürfen des Machtmissbrauchs führt.+1-1-1
    • Wenn die Entscheidung welche Datenquellen genutzt werden dem jeweiligen Plugin/Tool überlassen werden gibt es auch keinen "Machtmissbrauch".
  • -1-1-1-1
  • +1
  • +1 (bei Körbchen) aber -1 bei (Netzwerk)
  • Wir haben nicht die Öffentlichkeit, die uns das Vertrauen entziehen könnte. Im Moment sind wir unter uns und müssen die Grenzen austesten. (s. KA7)+1+1-1+1
    • das könnte sich bald ändern; immerhin ist der Leidensdruck hoch
      • -1, denn dann könnten wir das ja immer noch ändern.+1+1
      • -1
      • +1
        
        
• [KA6a] Der "Test" der Grenzen könnte schon sehr bald kein Test mehr sein, sondern bitterer Ernst und wir könnten dann in einer Situation sein, wo man das Rad nicht mehr einfach zurückdrehen und "Sorry" sagen kann. - Thema "Geschwafel-Flut"
  • erledigt
  • -1, denn momentan sind wir noch in der PoC Phase. Ich plädiere dafür (A) immer einen Schritt nach dem anderen zu tun und (B) jetzt die Probleme zu lösen die jetzt anstehen.+1+1+1
  • -1, die aktuelle Version ist explizit eine Beta und jeder, der auf eine Poc-Plattform oder den Ontology Explorer stößt, wird das zu lesen bekommen. Es ist dann klar, dass wir gerade ausprobieren. Niemand wird in Microsoft das Vertrauen verlieren, weil die Beta von Windows einen Festplattencrash verursacht. +1+1
  • -1, wir haben ein extra flexibles Plugin System und trotzdem Angst es könnte irgendwann nicht flexibel genug sein? Die Situation will ich erstmal erleben bitteschön bevor ich einen großen Aufwand treibe um sie zu vermeiden.+1
  • +1 (bei Körbchen) aber -1 bei (Netzwerk)
    
    

>>>=======ab hier beim nächsten Mal weiter =================<<<

• Wie verfahren wir bis nächsten Montag weiter ?
  • Kompromiss:
    • Autoren sollen gegebenfalls sagen, ob sie ihre Kernaussagen zurückziehen:
      • "Zurückziehen?"-Zeile hinzufügen (vom Autor der Kernaussage)
        • Andere  Teilnehmer können dieser mit +1 zustimmen, oder mit -1 Einwand gegen  das Zurückziehen erheben; diesen dann aber mit Begründung
          
          
• [KA7] Wir sollten es ausprobieren, herkömmliche Plattformen zu integrieren.
  • Zurückziehen? Mit Beschluss zu KA5 erledigt? +1+1 +1
  • +1+1+1=0
  • -1
  • +1, ja aber nicht jetzt. Erstmal sollte d!sco strukturiert und benutzbar sein bevor wir uns mit zusätzlichem Aufwand belasten.++1
    • s. Kommentar auf KA5: Wir brauchen verschiedene Plugins, sozusagen als Stresstest. Benutzbar wird d!sco erst durch verschiedene Plugins, zwischen denen man hin- und herschalten kann.
      • Ja und Nein. Benutzbar ist d!sco auch mit einem Plugin. Da lohnt der Aufwand natürlich noch nicht mit der Ontologie.
      • Nur weil es mehrere Plugins geben soll, muss man sich noch lange nicht mit den Unstrukturiertesten Varianten belasten am Anfang.
        • Na ja, ich habe ja schon ein PoC gemacht und denke, dass es sie nicht wirklich belasten wird. Bei der Entwicklung habe ich gemerkt, dass "automatisch" lästige, unbrauchbare Daten herausgefiltert werden - ohne, dass ich mich groß darum kümmere.
  • -1 Purismus ist Trumpf; eher sollte umgekehrt gedacht werden: Wir können ja erst mal puristisch ausführen, danach dann sozial alle denkbaren Register ziehen, um eine Community in d!sco auszubilden - Kooperation mit einigen, wenigen, lebendigen AGen, dann mehr AGen, Vorstände einbinden, Kooperation mit Parteitags-Antragskommissionen, Interviews, Stammtisch-Touren, etc. - und wenn das alles nichts nützt, DANN erst mal über Implementierung herkömmlicher Plattformen nachdenken.+1
    
    
• [KA7/2] Wir sollten es zulassen, dass jemand ein herkömmliches PoC-Ausprobier-Plugin entwickelt und integriert.
  • Zurückziehen? Mit Beschluss zu KA5 erledigt? +1+1
  • +1+1
  • +1, solange kein Plugin gezwungen ist mit den Daten klar zu kommen. Siehe Filtermöglichkeiten [KA11]
    • Das verstehe ich überhaupt nicht. Wer nicht "mit den Daten klar kommt" kann doch wohl nicht Plugin sein!??
      • Damit meinte ich z.B. sehr unstrukturierte Texte ohne Zusammenhang zu anderen Posts die in manchen Plugins einfach nicht sinnvoll dargestellt werden können. Andere Plugins erwarten evtl. eine klare Einsortierung der Posts in Frage/Pro/Con, was nicht immer gegeben ist. Solche Daten können ausgefiltert oder evtl. mit entsprechendem Aufwand aufbereitet werden.
  • -1 Falls wir kein herkömmliches PoC-Ausprobier-Plug-In in d!sco haben wollen sollten, wäre die Müh' da ja umsonst bzw. normative Kraft des Faktischen vermeiden; nicht dass es nachher heißt "Jetzt haben wir eins, in dessen Entwicklung flossen so viel Ressourcen, dann müssen wir's jetzt auch verwenden, sonst wär' das gemein gegenüber Entwickler Y"+1+1
    
    
• [KA8] Es wird zwangsläufig Daten geben, die für manche Plattformen unbrauchbar sind.
  • +1+1+1+1+1+1
  • KONSENS
    
    
• [KA8a] Angenommen, KA8 stimmte. Daraus folgt, dass es immer ein gewisses "Geschwafel" aus der Sicht gewisser Plattformen gibt.
  • Zurückziehen? Mit aktuellem Verständnis der Planung, siehe Stichworte P2P, Whitelist, Blacklist eledigt? +1+1+1
  • +1+1+1+1
  • -1 Geschwafel impliziert ja weit mehr Unannehmliches als lediglich semantisch-unvorteilhaft empfundene Ausführungen; Rhetorik, Off-Topic, Persönliches, etc. sind im Rahmen einer Sachdiskussion auch Geschwafel
    • Dann müssen wir aber darüber sprechen, ob beispielsweise übermäßige Rhetorik oder Off-Topic in keinem unserer Plattformen möglich ist. Es wird auch hier Differenzen geben. Wenn eine Plattform mit möglichst aller Struktur keine Nachteile hätte, müssten wir die Diskussion nicht führen.
    • Ja aber diese können trotzdem von verschiedenen Plattformen unterschiedlich bewertet werden.
  • Eigentlich soll d!sco doch die Stärken der einzelnen Plugins vereinigen. So gesehen wäre es ein Grundfehler, alles als "Geschwafel" abzutun, was aus der Sicht des gerade benutzten Plugins "unbrauchbar" ist. Viel eher müsste doch das "d!sco-Zentral-Tableau" eine Übersicht der Alleinstellungsmerkmale (im Sinne von Stärken!) aller Plugins anbieten. Dann könnte jeder Nutzer gezielt zu demjenigen Plugin wechseln, mit dem er seine Daten "besser" anbieten und bearbeiten kann!+1
    • bzw. das ihm hilft, die Plattform zu finden, die ihm am besten gefällt. Die User werden sicher nicht schauen, wo ihre Daten gut reinpassen, sondern wo sie am meisten erreichen können. Ist das nicht durchs Hin-und-Herschalten zwischen Plugins gewährleistet?
      • Nein. Um das durch trial and error erkennen zu können, müsste man sich ziemlich intensiv mit allen anderen Plugins beschäftigen. Das wird kaum jemand tun können.
        
        
• [KA8a.b] Daraus folgt, dass man dieses Problem durch Mechanismen wie Filter lösen muss. Falls KA1 falsch ist, ist d!sco also nicht umsetzbar.
  • Zurückziehen? Mit aktuellem Verständnis der Planung, siehe Stichworte P2P, Whitelist, Blacklist eledigt? +1+1+1+1
  • +1+1+1+1
  • -1 Semantische Probleme sind rausfilterbar; alle anderen Diskussionsprobleme herkömmlicher, öffentlicher Kommunikationsmittel löst man am besten, indem man 'nen saubren Bruch zu ihnen macht. Das Geschwafel-Problem ist also nicht rausfilterbar und wenn KA1 falsch ist, folgt daraus nicht, dass d!sco nicht umsetzbar ist.+1
    • Nochmal: Warum sollte sich in unseren Plugins nicht auch mal Geschwafel bilden? Zumindest aus Sicht des qKonsens wird viel Geschwafel existieren. In etwas geringerer Ausprägung wird das auch den anderen Plugins so gehen. Wenn die nicht filtern können, haben wir ein Problem.
    • Der sauberere Bruch sollte zu jedem Plugin möglich sein das aus der eigenen Perspektive zu sehr "schwafelt".   aber wie??
      • Indem für das eigene Tool notfalls die störenden Tools als Datenquelle komplett ausgeschlossen werden.
  • Solch ein Filter müsste dann aber ziemlich listig sein. Denn er wird den Menschen die kreative Arbeit nie abnehmen können - er kann nur helfend zeigen, wo welche Arbeit nötig ist - um ein besseres Ergebnis zu erreichen - nur darum sollte es doch gehen?!!
    • Wenn z.B. ein unstrukturierter Text zu qKonsens transferiert werden soll, dann kann ein Filter zunächst nur die "Abschnitte" erkennen. Zu jedem Abschnitt legt der Filter eine leere(!) Kernaussage an, und den Textabschnitt selbst packt er vorerst in den Kommentar zu dieser Kernaussage. Allenfalls können themenspezifische Tags im Textabschnitt ermittelt und als Rohmaterial im Texteditor für die Kernaussage bereitgestellt werden. Das wäre mMn das Maximum dessen, was ein Filter als Unterstützung für den Bearbeiter-Mensch leisten kann.
      • Alternativ kann der Filter den unstrukturierten Text aus qKonsens komplett raushalten, damit er nicht stört. Sorry - aber der unstrukturierte Text wird ja überhaupt nur in qKonsens hineingezogen, wenn dessen Funktionalität genutzt werden soll!?!
      • Ah verstehe. Filter sind hier meist so gemeint, dass sie Daten herausfiltern, also verwerfen, nicht dass sie Daten aufbereiten. Das wäre tatsächlich schwierig automatisch zu erreichen, da gebe ich dir recht. +1 Nur: siehe 287! Der Sinn von d!sco liegt doch nicht im Verwerfen, sondern im Zusammenführen! Deshalb rede ich auch viel lieber von Export/Import als von "Filter".
      • Zustimmung. Den Begriff "Filter" sollten wir weiterhin fürs Verwerfen nutzen. Export/Import ist ein hohes Ziel und ich bin optimistisch, dass viele Nutzer oder Plugin/Tool-Verwalter da Arbeit rein stecken. Die Dinge die nicht automatisch übernommen werden können müssen ja nur herausgefltert werden bis ein akzeptabler Import/Export verfügbar ist.
    • Soll hingegen ein Thread aus einem Forum zu qKonsens transferiert werden, so liegt zwar eine strenge Struktur vor - aber die Kernaussagen sind darin wohl meist eher versteckt als expliziert. Für diesen Fall habe ich keine bessere Idee, als den ganzen Thread zunächst als Diskussion zum Debattenkopf zu platzieren. Der Bearbeiter_Mensch müsste dann  handisch einsortieren, was "Kernaussage", was Kontext/Beitext und Kommentar zu diesen Kernaussagen - und was dann noch "Diskussion" ist.+1 Vermutlich ist auch hier das Stationen-Konzept des qKonsens hilfreich: eine Station mit dem Rohmaterial - und dessen Aufbereitung als "ganz normaler" Übergang zur nächsten Station...
      • Genau. Ich kann mir z.B. gut vorstellen dass einzelne Tool/Plugins hier die Rolle der Stationen übernehmen können. Kann natürlich auch innerhalb eines Tools realisiert werden.((Da müsste d!sco:Station klar im Unterschied zu qKonsens:Station definiert werden. Fände ich nicht gut.))Der qKonsens ist ja nicht das einzige Tool das Daten aufbereiten will. Aber ich bin im Stationenkonzept nicht drin. Ich denke mal das wird schon passen.
        
        
• [KA8b]... aber nicht so massenhaft wie von einem herkömmlichen Diskussionssystem
  • Zurückziehen ? +1(ist zwar inhaltlich richtig, aber bereits weiter oben erwähnt ("Serverlast")) +1(ist keine Kernaussage)+1+1+1+1
  • -1, denn das ist eine These, die wir mit dem PoC entweder bekräftigen oder entschärfen könnten. Augenblicklich ist es jedoch reine Spekulation.+1-1(keine Spekulation, sondern sehr oft erlebter bitterer Alltag -> gutes Bsp : Diskussion vom 27.10. zum 28.10. auf unserer Liste)
  • -1, Masse ist höchstens für die Serverlast/Netzlast entscheidend, nicht für Filtermechanismen.+1
  • Beispiel: Aus Sicht des qKonsens wird massenhaft Müll produziert, der nicht einfach eine Kernaussage ist. Warum ist man also bei Foren strenger?+1
  • -1, kommt auf die Datenquellen an und darauf wie die Plattform Geschafel definiert [KA8a]
  • -1 Es gibt keine herkömmlichen Diskussionssysteme, sondern nur herkömmliche, öffentliche Kommunikationsmittel, die für Diskussion genutzt werden, obwohl sie dafür ungeeignet sind.
    • Begriffskleinigkeiten - über "Diskussionssysteme" sind wir uns noch nicht einig, was das ist.
      
      
• [KA9] Plattformen können anhand der Semantik (die maschinenlesbare) entscheiden, welche Inhalte sie herausfiltern möchten.
  • Zurückziehen? irrelevant +1+1+1+1+1
  • Zuvor eine Verständigungsfrage: Für mich sind "Semantik" und "maschinenlesbare Daten" zwei völlig verschiedene Paar Schuhe. Semantik (Bedeutung!) ist zunächsst nicht "maschinenlesbar", und im Maschinenlesbaren enthaltene Bedeutung ist für Maschinen ebenso wenig erkennbar. Erst die Ontologie schafft bestenfalls die Brücke, über die Bedeitung maschinenlesbar wird.
    • Gemeint ist hier nur die maschinenlesbare Semantik wie in der d!sco Ontologie definiert, soweit die Daten bereits entsprechend angereichert wurden.
    • Dann ist KA9 ein typisches Beispiel, dass Kernaussagen in einem Kontext erklärt werden müssen: hier das "können" betreffend.
      • Deshalb die Klammer: "(die maschinenlesbare)"
    • Ja, die Frage ist eigentlich gar nicht das können, da das mit der Ontologie gegeben ist, sondern ob eine Filterung die nur darauf basiert auch ausreichend ist.
  • +1
  • -1, es ist nicht garantiert, dass alle die Ontologie korrekt nutzen und keine Graubereiche bleiben. Oft kann nur anhand der Datenquelle entschieden werden.
    • Diese Möglichkeit ist inzwischen eindeutig gegeben (Stichwort Whitelist). Einwand ist damit erledigt.
  • -1, dazu müssten alle Daten betrachtet werden.
    • Solange die Daten maschinenlesbar sind... Um den Aufwand ging es mir nicht.
  • -1 das gilt nur beschränkt; genauer gesagt in semantischer Hinsicht, nicht jedoch bzgl. Inhalte, die anderwaltig als schlecht einzustufen sind (Polemik, Off-Topic, Rhetorik, etc.)+1
    • Bei Polemik, Off-Topic und Rhetorik müssen wir darüber Reden, ob das bei unseren Plugins nicht möglich ist; in Multilectics z..B. wird sowas nicht verhindert, sondern in der Meta-Diskussion aufgedeckt bzw markiert und so entschärft
    • Es ging hier ja um maschinenlesbare Semantik.
      
      
• [KA10] Sobald d!sco P2P existiert, lautet die neue Problemstellung: "Wie bekommen wir eine "gemeinsame Sprache" hin, durch das die Plattformen möglichst vollständig ihre Inhalte austauschen können?"
  • +1++1
  • +1, gemeinsame Sprache = unsere Ontologie (Sem) / P2P Protokoll (Tech) / Filter API (Tech) (OData / SPARQL) +1+1
  • KA20
  • Interface finde ich keine glückliche Bezeichnung. Bleiben wir doch einfach bei Ontologie.  Das passt doch gut. Was innerhalb des d!sco P2P Netzwerkes abgehen wird  kann man dann auch gut als Semantic Web bezeichnen. Wir benötigen das  P2P Netzwerk mMn 'nur', um uns bzw. d!sco vor zu viel Datenmüll zu  schützen, bzw. damit es für Such-/Filteranfragen und Synchronisation  einfacher wird die relevanten Server Knoten zu identifizieren.
    • verbessert
  • +- 0 Kann ich als Nicht-Tekkie nicht abschätzen
    
    
• [KA10a] Auch ohne P2P-Netzwerk macht es Sinn d!sco als Interface/Protokoll zu nutzen, statt als Datenbank, da ein einzelnes Plugin das zu viele, unstrukturierte oder "falsch" strukturierte Daten erzeugt so keine Probleme mehr macht.
  • Erledigt mit den geplanten Filtermöglichkeiten. +1+1+1+1
  • +1, Definition von Interface in diesem Fall?
    • d!sco wäre zunächst mal eine Sammlung von Definitionen, so dass PlatformX --> getArgumentsWith( "bla" ) eine klare Bedeutung hat.
      • Dafür dient die Ontologie+1
        • Exakt. Nur dass sie bisher nur Daten aus der Datenbank abruft und hier die Daten auch verarbeitet. "Serverseitiges Filtern, Verarbeiten"
          • Mangels PoCs die es als Interface nutzen könnten. Sollte IMHO nur ein Übergangszustand sein.
          • schaut Euch nochmal dieses Bildchen an
          • Lassen sich vielleicht an diesem schönen Bildchen die diskutierten Begriffe erklären und zuordnen? Meint "database" ausschließlich nach der d!sco-Ontologie definierte Daten? Ist "Call" ein "Interface"? Was ist "Protokoll"? Kann der Empfänger verlangen, dass der Sender gefilterte Daten liefert? Wie groß sind die Schritte zwischen den Typen A,B,C? uswusf.
          • http://wiki.piratenpartei.de/wiki/images/3/37/DiscussionSystem-Overview.jpg ://wiki.piratenpartei.de/wiki/images/3/37/DiscussionSystem-Overview.jpg
            • Im Bild liegen alle Daten im P2P Netzwerk? Ist ne Möglichkeit, aber ich wünsche mir die zusätzliche Option eben nicht die gesamte P2P-Datenbank zu nutzen sondern nur von ausgewählten anderen Plugins Daten zu beziehen.
              • Jeder Datensatz hat auch seinen Ursprung, sein Plugin als Eigenschaft, die Bedingung für die Nutzung sein kann. (Tendiere eher zu einem Opt-out-Ansatz, ist aber dem Plugin überlassen.)
              • Wichtig ist, dass man nach Ursprung filtern kann ohne erst die ganze Datenbank runtergeladen zu haben.
          • Aber eine Ontologie bietet weniger Möglichkeiten als ein Interface. Iwf?
            • Eine Ontologie ist eine Datenstruktur, ein Interface kann die Informationen je nach aufgerufener Funktion unterschiedlich verarbeiten. Ganz nach C#-Manier.
              • Ok nach der Definition reicht Evtl. Ontologie&Filter ... aber ob das dann noch so weit weg ist von einem Interface?
              • -1 Das Interface ist 'nur' eine Schnittstellenbeschreibung und kann selber keine Funktionen ausführen. Code, der das Interface implementiert, enthält dann die entsprechenden Funktionen, welche ausgeführt werden können. Für Progger ist Interface einfach ein stehender Begriff. Lasst ihn uns daher besser nicht in diesem Kontext verwenden. Bleiben wir besser bei Ontologie als Begriff.
              • Aber über das Interface wird auf vom Hoster bestimmte Funktionen zugegriffen, über deren Implementierung nichts bekannt ist.
              • Ich hätte vllt. lieber Protokoll sagen sollen, da wir den Begriff in der Diskussion früher schon mal hatten und damit etwa das gemeint war was ich will.
    • Ach so, mehr serverseitige "Funktionen", um auf die gewünschten Daten zuzugreifen?
      • Ja, in weiteren Schritten könnte d!sco auch ein Plugin für die Plattformen werden das die Arbeit vereinfach ein solches Interface anzubieten. Idee ist, dass PlattformY bei Interesse alle interessanten Daten von PlattformX kriegen kann und diese in vorhersehbarer Struktur erhält.
      • Und das natürlich wie schon angedacht per P2P-Netz den Datenaustausch verbessert ohne dass der Plattformbetreiber sich da groß drum kümmern muss.
  • +1, damit würde auch nichts mehr gegen ein Mailing Listen Plugin oder ähnliches sprechen.+1
  • + Auf 'ner funktionierenden, guten Ontologie aufzubauen ist natürlich 'ne gute Idee.+1+1
    
    
• [KA11] Die Filtermöglichkeiten müssen umfangreich, universell und leicht einsetzbar sein, ohne die gesamte Datenbank herunterladen zu müssen.
  • Teilnahme ohne komplette Datenbanksynchronisierung wurde beschlossen. Somit erledigt? +1+1, weil Konsens; technische Details vertagt+1
  • +1+1(frommer Wunsch?)
  • +1, die Einfachste Möglichkeit wäre hier IMHO ein Opt-In für einzelne Plugins.
    • Dann könnten sich neue Plugins aber sehr schlecht durchsetzen. Sollte mMn den Plugins überlassen sein.+1
      • Die einfachste Möglichkeit muss ja nicht die Einzige sein ;-)+1
  • Man könnte auch Filterabonnements anbieten, die von Plugins genutzt werden können (outgesourcte Interfaces)+1
  • universell: vom Plugin an die Anforderungen anpassbar.
  • Wenn wir in der Terminologie der Ontologie bleiben, dann könnten wir als Filtermechanismus den SPARQL Standard verwenden. Momentan (zentrale Instanz) nutzen wir hierfür OData.
    • Schau ich mir mal an
  • +1 klingt ja sinnvoll
    
    

Grundlegend zu allen [KA12*]: Sind diese Definitionsfragen noch wichtig nachdem in der aktuellen Planung sowohl Diskussionssysteme als auch herkömmliche Kommunikationsmittel ihren Platz finden?

• Sind erledigt: +1+1
• vertagen +1+1+1+1+1
  • bis nach PoC aber VOR dem großen Coming Out!+1
• Muss geklärt werden: =0+1+1
  • +1, denn wir sollten Begriffe wie "Diskussionssystem" einheitlich verwenden, wenn wir nicht in weiter Missvertändnisse hineinstolpern wollen
• [KA12] Ein höheres? Diskussionssystem ist ein Kommunikationsmittel, das durch seine Struktur das Diskutieren rundum optimiert
  • Vorschlag:
    • vertagen, aber auf wenig definierte Begriffe zugreifen?
      • höheres, optimiertes, 2nd-Generation-
    • strukturiertes Diskussionssystem? +1-1
    • optimiertes Diskussionssystem? +1+1+1
    • ergebnisorientiert -1
    • kollaborativ -1+1
    • Diskussionssystem 2. Generation +1
    • höheres Diskussionssystem +1+1+1
  • Frage: sind wir uns einig, dass 
    • (A) Diskussionssystem ALLE möglichen Tools/Plattformen beinhalten kann, die zum Diskutieren gebraucht werden können?+1+1+1+1
    • (B) Diskussionssystem werden anhand eines Kriterienkataloges klassifiziert.+1 +1++1+1
  • Einspruch, Euer Ehren: um bewerten zu können, ob ein System ein Diskussionssystem  ist oder nicht, müssten wir mMn zuerst einmal Kriterien festlegen. +1
    • Das ist doch schon ein allumfassendes Kriterium; man kann's allerdings sehr wohl noch aufschlüsseln --1(allumfassend?? aber keinesfalls verifizierbar!?!)
    • Wie wär's mit "Marktmechanismen"/Evolution? Plugins, die von anderen Diskussionssystemen angenommen werden, sind höchstwahrscheinlich auch welche und nützlich für d!sco. (Siehe in anderer Interpretation KA1a/b)+1
    • -1, Fest definierte Kriterien lassen sich doch in einem P2P nicht umsetzen...+1
  • +1, auch wenn ich hier die Struktur nicht als einziges Mittel sehe. Allerdings als für mich persönlich wichtigstes.
  • -1, du meinst damit doch:  Diskussionssysteme optimieren die öffentlichen Diskussionsmittel. Wenn  man die als Bezugspunkt nimmt, ist natürlich klar, dass sie sich nicht  selbst optimieren. Liegt dann allein an der auf sie abgestimmten Definition.
  • Die folgenden Kriterien von dir sollten mMn Qualitätskriterien und nicht Ausschlusskriterien sein.
  • +1
    
    
• [KA12a] Von [KA12] ausgehend ist ganz konkret ein Kriterium, dass Diskussionssysteme eine Diskussion nicht chronologisch, sondern inhaltlich ordnen
  • +-0, als Qualitätskriterium nützlich, es gibt Ausnahmen (s.u.)
  • -1, nicht immer: So gibt es beim qKonsens auch die Möglichkeit, unter einer KA linear über diese zu diskutieren. Das wäre ein chronologischer Teil - einem Board entsprechend.+1+1+1
    • wobei sich da die Frage stellt, wie vorrangig sortiert wird. Ich nehme an, dass der default-Modus beim qKonsens inhaltlich-ordnen ist +1 Ja, die KA sind natürlich innerhalb einer KK "inhaltlich geordnet"
      • Wie ich es verstanden habe, gibt es beides: eine lineare Verständnisdiskussion unter der KA und eine vertiefte KK-Diskussion als Konsenskiste. Solche Features sind jedenfalls nicht ausschließbar. Vorteil ist zum Beispiel die geringere Komplexität (!).++1
  • +1
  • -1 ich würde die KA12a löschen. Unstrittig ist auch für mich, dass der Sinn eines Diskussionssystems ohne inhaltliche Ordnung nicht erreicht werden kann. Ich würde aber andererseits nicht alle Welt bekehren wollen, dass Foren und Bords und Mailinglisten keine Diskussionssysteme sind...
  • Auch Foren und Mailinglisten sind in Grundzügen "inhaltlich geordnet". Das ist eine Abstufung. Eine solche ist schlecht als Ausschlusskriterium zu gebrauchen.
    
    
• [KA12b] Von [KA12] ausgehend ist ganz konkret ein Kriterium, dass Diskussionssysteme den Leseaufwand verringern, der erforderlich ist, um sich eine Diskussion inhaltlich im Wesentlichen vor Augen zu führen.
  • +1+1+1, nicht nur, aber auch +1
  • Qualitätskriterium passt mMn besser
  • Das muss so sein, wenn es um hunderte User geht.
  • Das ist eine gewagte These. Sehe ich eher als Aufgabe eines Informationssystems (Textrapic)
    • Textrapic kann für Informationsverdichtung verwendet werden; wenn es jedoch so ausgeführt ist, dass es ausschließlich nach Diskussionselementen fragt - persönliche Meinungen zu einer Sach-Diskussion - dann ist es ein Diskussionssystem; oder umgekehrt gesagt: Nur weil ich Wikiarguments oder den qKonsens mit harten, unbestreitbaren Daten und Fakten fluten kann, macht es diese Diskussionssysteme ja noch lange nicht zu Informationssystemen ;) ...
    • Die  Grenze zw. Information und Diskussion verschwimmt leicht. Und  geringerer Leseaufwand ist auch bei der Strukturierung von Diskussionen  sehr wichtig!+1+1
      
      
• [KA12c] herkömmliche öffentliche Kommunikationsmittel wie ML/Forum/newsgroup/Twitter sind folglich keine Diskussionssysteme
  • -1, sie sind schlechte Diskussionssysteme. Eine minimale Struktur und thematische Sortierung ist durchaus vorhanden.+1-1
    • Diese minimale Struktur ist unumgänglich für jegliche Kommunikationsmittel und stellt keine spezifische Optimierung für das Diskutieren da
      • Da sind die Grenzen fließend. Gab durchaus Stimmen die ein normales Forum + etwas integrierte Bewertung schon als sehr gutes Diskussionssystem sehen würden. +1
  • -1 slash, deine genannten  Kriterien betreffen keineswegs die Definition für Diskussionssysteme!  Wie der Name sagt, sind sie Systeme, um zu diskutieren! Das sind auch  die Öffentlichen.
  • +1
  • -1 Was soll die Ausschließeritis? Wenn eine Brücke von solchen "öffentlichen Kommunikationsmitteln" zu d!isco gebaut werden kann - warum nicht??+1
    
    
• [KA12d] qKonsens, Multilectics, X-Tree-M, fundiert-entscheiden, Findeco, Votorola,  incoma, wikiarguments, etc. sind folglich Diskussionssysteme
  • +1+1+1+1
    
    
• [KA12e] alternativ zu [KA12]. Ein Diskussionssystem ist jedes beliebige System das genutzt wird um Diskussionen zu führen, zu dokumentieren, zu strukturieren oder mehrere davon.
  • Es wird tendenziell besser wenn Qualitätskriterien wie [KA12a], [KA12b] und [KA12f] erfüllt werden.+1
  • +1+1
  • -1 damit entkernt man den Begriff des Diskussionssystems von seiner Bedeutung und steht dann am Ende ohne begriffliche Unterscheidungsmöglichkeit zwischen jeder X-beliebigien Kommunikationsstruktur und Kommunikationsstrukturen da, die dafür konzipiert sind, das Diskutieren rundum zu optimieren. Dieser Verlust erschwert auch das Unterfangen d!sco und widerstrebt dem Selbstverständnis vieler Diskussionstool-Entwickler, die sich ja aus Frust von dem "herkömmlichen unnützen Brei" radikal los-eisen wollen. Wenn sowas wie wikiarguments oder Findeco erwähnenswert anders ist, als eine Mailingliste oder Twitter, muss das auch in einem eigenen Begriff Ausdruck finden, der Systeme wie diese von Mailinglisten und Co. unterscheidet.
    • Foren sind durchaus zum Diskutieren und nicht nur zum Kommunizieren designt worden. Sie vom Begriff auszuschließen, entkernt ihn. Wie oben beschrieben, ist es doch nicht zulässig, zu sagen, dass Diskussionssysteme die Herkömmlichen verbessern, und daraus zu schließen, dass diese keine sind. Das ist Ausschluss ohne Begründung explizit per definitionem. ++1
    • Ich finde schwierig das geforderte "rundum optimieren" in einer nachvollziehbaren Art scharf zu definieren. Deine in [KA12*] vorgeschlagenen Merkmale können immer auch teilweise bzw. unterschiedlich gut umgesetzt sein.+1
      • Antrag an slash: Vielleicht Kriterium in Qualitätskriterium statt Ausschlusskriterium abändern?
        • Slash geht es aber gerade um die ausschließende Begriffsdefinition. Qualität ist eine andere Baustelle. (Und definitiv leichter zu definieren).
  • Ich erkenne die gute Absicht, finde sie aber nicht hilfreich. Eine "Diskussion führen" ist doppeldeutig: landläufig wird darunter ungeführtes(!) palavern verstanden, und der Gegensatz "Führung einer Diskussion" ist sehr vielschichtig. Und dann fehlt unter den Kriterien noch die Ziel- oder Ergebnis-Orientierung.  Das ist  mMn überhaupt das wichtigste Kriterium. Aber das ist vielleicht auch der Schritt zum "Willensbildungssystem" - also zu der oben angesprochenen Unterscheidung gegenüber "einfachen" Diskussiossystemen...
    
    
• [KA12/2] Alternativ zu KA12 und 12e. Ein Diskussionssystem ist jedes Tool, das dazu konzipiert ist oder mit dem es möglich ist, zu diskutieren.
  • +1
    
    
• [KA12f] Von KA12 ausgehend ist ganz konkret ein Qualitätskriterium, dass eine Plattform von den Usern akzeptiert und auch genutzt wird. (Den Fall angenommen, dass sich auf der Plattform schon genügend Leute tummeln, dass sie nutzbar wird.)
  • +1
  • -1 Qualitätskriterien können imho nur technisch sein; Beispiel: PCGH-Forum - genießt große Community-Akzeptanz, aber macht das das PCGH-Forum auch nur im geringsten zu einem Diskussionssystem ? Nein.
    • Das ist ein Kriterium. Es ist genau so wichtig wie die technischen. Umkehr-Beispiel: Eine Plattform, die total durchstrukturiert ist, und dadurch wegen der Umständlichkeit nicht genutzt wird, bringt der Welt nix. Dir geht's doch auch um einen "WOW-Effekt". Auch das ist ein Qualitätskriterium.
      • Sie bringt nix, wäre aber ein Diskussionssystem. Slash geht es um Begriffsdefinition, nicht um Qualität.
        • Genau, Qualitätskriterien sind nicht absolut, im Gegensatz zu Ausschlusskriterien.
  • Da sind wir wieder beim Marketing. Beste Qualität hat dann, was am erfolgreichsten beworben wird.  Ist höchst beachtenswert!  Weckt bei mir aber unerfreuliche Assoziationen. Würde ich nicht mit "Qualität" identifizieren...
    
    
• [KA13] Bisheriger Konsens war, dass es nur ein einziges Kriterium zur Aufnahme in d!sco gibt, nämlich: "Ist der Kandidat ein Diskussionssystem?" - wenn ja, Aufnahme, wenn nein, dann nicht; Belege hierfür finden sich zahlreich in der Grundidee*
  • Nachdem die d!sco Struktur klarer geworden ist momentan irrelevant/erledigt? +1+1+1+1
  • EINGEFROREN
    • Bis dato schwamm der Begriff "Diskussionssystem" halt
      • Blacklist und Whitelist wirklich erforderlich
      • Filter-Abonnements auch wichtig
  • Ja, aber jeder kann ein Plugin schreiben, das diese Aufgabe beliebig gut oder schlecht erfüllt.+1
  • +1, eine zentrale Datenbank sollte nur mit hochwertigen Quellen gefüttert werden.+1
  • Frage: Was wäre die Konsequenz einer Nichtaufnahme? Im Protokoll/Interface Szenario wäre das Plugin als Freiwillige Datenquelle trotzdem für alle verfügbar.+1
    • KA1a/b?Genau
  • Um bestimmen zu können was ein Diskussionssystem ist und was nicht, benötigen wir mMn zwingend einen Kriterienkatalog zur Bewertung. +1-1-1
    • Es lässt sich auch dadurch bestimmen, ob die anderen Plugins es akzeptieren und die enthaltenen Inhalte verwerten können.+1+1+1
  • +1+1
    
    
• [KA14] Unsere bisherige Diskussionskultur - also auf herkömmlichen öffentlichen Kommunikationsmitteln basierend - ist echt scheiße; durch eine Import-Struktur, die massig aus der herkömmlichen Diskussionskultur in d!sco reinimportiert, verschlechtert sich insgesamt das Niveau von d!sco.
  • Erledigt nach aktuellem Verständnis, Stichwort Whitelist? +1+1+1+1
  • +-0, kommt drauf an wie es geschieht. Siehe [KA1a/b],[KA20]
  • +-0 Trifft mMn nur auf die zentrale Datenbasis zu+1
    • Bei Gebrauch des P2P eröffnen sich nämlich viele neue technische Möglichkeiten, dass die Plugins jeweils selbst entscheiden, ob sie bestimmte Plattformen ausschließen.
  • +1
    
    
• [KA14a] Der Punkt [KA14] fällt allen Diskussionssystemen innerhalb von d!sco zulasten, insbesondere den besseren.
  • Erledigt nach aktuellem Verständnis, Stichwort Whitelist? +1+1+1+1
  • +1
  • +1, falls das Plugin falsche Daten einspeist oder den Server überlastet
  • -1, falls es unvollständige und wenige Daten einspeist - in diesem Fall ist es ein Leichtes, unvollständige Daten zu erkennen und herauszufiltern.
  • +1
    
    
• [KA14b] Der Punkt [KA14] schreckt Diskussionstool-Entwickler davon ab, bei d!sco mitzumachen.
  • Erledigt nach aktuellem Verständnis, Stichwort Whitelist? +1+1+1+1
  • -1, kommt drauf an ob die "schlechten" Daten leicht vermeidbar sind. Siehe [KA11],[KA1a/n],[KA20]
    • Das scheint der Fall zu sein.
  • +-0 Falls KA14 stimmt.+1
  • +1
    
    
• [KA14c] Der Punkt [KA14] schreckt User davon ab, bei d!sco mitzumachen.
  • Erledigt nach aktuellem Verständnis? +1+1+1+1
  • -1, der User macht nicht bei d!sco mit sondern bei einem Plugin. Wenn dieses gut in der Lage ist zu filtern hat der User keine Nachteile.+1+1
  • +1
    
    
• [KA14d] Der Punkt [KA14] verlangsamt die Weiterentwicklung von d!sco.
  • Erledigt nach aktuellem Verständnis? +1+1+1
  • +1, spricht für ein Aufschieben der konventionellen Plattformen bis ein P2P/Interface/Protokoll System steht.+1+1
  • +1
    
    
• [KA15] Die User da mitnehmen, wo sie sind, geht nur über Forum/ML/newsgroup-Integration":
  • ANTIKONSENS, erledigt
  • -1 Gegenbeispiel "Kandidatenportal von Fulleren anlässlich NRW-Aufstellungsversammlung zur BTW13"
  • -1, das Abholen kann auf andere Art geschehen. Z.B. indem gezielt besonders komplexe Diskussionen in d!sco repliziert werden um am konkreten Beispiel die Vorteile aufzuzeigen.
  • -1
  • -1 
    
    
• [KA16] Eine Implementierung von ML/Foren/newsgroup/etc. hat gegenüber betriebssystembasiertem Copy & Paste keinen erheblichen praktischen Mehrwert und ist somit unnütz und wird von niemandem in der Praxis genutzt
  • vertagen? +1+1
    • Ausprobieren? +1+1+1+1
  • Wie soll der Rücklauf aussehen, also d!sco = zurück zu => ML/Foren/etc.
  • dafür kann der PoC ja genutzt werden, um genau solche Fragen zu beantworten.
    • Aber selbst, wenn man diese Richtung einschlägt, muss dieser Schritt doch zumindest so weit definiert werden, dass grob abschätzbar ist, ob Mehrwert in Aussicht steht, oder nicht; und das seh' ich bislang noch nicht.
      • Sehe ich auch so. Früher oder später wird das sicher jemand implementieren der diesen Mehrwert sieht. Bis dahin sollten wir keinen Aufwand betreiben und danach aufpassen, dass es keine Nachteile gibt.
        • Verweis zu KA7/2 (für die Diskussion)
  • -1 Mir schwebt was vor, wie auch Foren in multilectics einen Nutzen haben können.
    • Wie sieht das denn aus, was Copy & Paste pragmatisch schlagen könnte?
      • In Multilectics soll es Möglichkeiten geben, Daten semantisch zu vervollständigen, wenn man auf sie stößt. Geht natürlich nur, wenn sie in d!sco integriert sind. Sobald sie genug Semantik besitzen, werden sie von den anderen Tools nicht mehr herausgefiltert und erzeugen einen Mehrwert.
      • Das schlägt Copy/Paste, weil es keine stupide Sklavenarbeit (bei langen Diskussionen) ist, sondern jede Handlung sorgt für semantischen Mehrwert
  • -1 würde den Nutzen nicht kategorisch ausschließen, eine automatische Semantikanreicherung und Filterung ist aber mit Sicherheit keine einfache Aufgabe.+1
  • +1+1
  • -1 (irrelevant! überladene Aussage; Foren usw. sind Fakt; C&P ist Fakt; beides kann zusammen genutzt werden; z.B. wird der kreative Akt beim Stationsübergang im qKonsens wie auch so manche Moderatorenaktion selbstverständlich mit C&P realisiert; und die Diskussion der einzelnen Kernaussage wird eine Art "Forum" sein...)
    
    

>>>=======ab hier beim nächsten Mal weiter =================<<<

• Wie verfahren wir bis nächsten Montag weiter ?
  • Kompromiss:
    • Autoren sollen gegebenfalls sagen, ob sie ihre Kernaussagen zurückziehen:
      • "Zurückziehen?"-Zeile hinzufügen (vom Autor der Kernaussage)
        • Andere   Teilnehmer können dieser mit +1 zustimmen, oder mit -1 Einwand gegen   das Zurückziehen erheben; diesen dann aber mit Begründung
          
          
• [KA18] man sollte mal die unterschiedlichen Modi durchdeklinieren, was überhaupt für Wege da sind
  • Erledigt nach aktuellem Verständnis? +1+1(keine Kernaussage)+1+1+1
    
    
  • [KA18a] d!sco ohne jegliche Implementierung von herkömmlichen öffentlichen Kommunikationsmitteln
  • [KA18b] d!sco + Andock/One-way/Brücken-Element (herkömmlichen öffentliche Kommunikationsmittel)
    • Frage: Andock/One-way/Brücken-Element meint das Gleiche wie Interface/Protokoll? Siehe [KA1a/b]
      • Glaube nicht, One-way soll wohl für read-only stehen.
        • (...)
        • Ja ok also Interface + kein Schreibzugriff auf die zentrale Datenbasis, was eh igendwo entschieden werden muss.+1
        • Für die zentrale Datenbasis machen wir das doch. Wir können nach den Kriterien auswählen, welche Plugins auch Schreibzugriff auf die Ontologie bekommen und welche nicht.
        • Genau und da müssen wir uns dank Interface Ausweichmöglichkeit dann auch keine Zensurdebatte anhören. (Siehe KA1a/b, KA20)
  • [KA18c] d!sco + Plug-In-Element (herkömmlichen öffentliche Kommunikationsmittel) -  also strukturell auf einer Stufe mit all den Diskussionssystemen, die im  Meta-Diskussionssystem d!sco integriert sind
  • [KA18d] d!sco + Plug-In (Diskussionssystem + Andock/One-way/Brücken-Element)
    • Ist das nicht DER Win-Win-Konsent schlechthin ? Nur Diskussionssysteme in d!sco, eines dieser ist jedoch wiki9999, Architecture for democracy 2.0?, MakeYourLaws?, InterMix.org? oder sonst ein Diskussionssystem, was Import von herkömmlicher öffentlicher Kommunikationsstruktur beinhaltet
    • ich versteh' sowieso nicht, warum - wenn überhaupt - sowas unbedingt an das Grundgerüst, und nicht etwa an eines der Plug-Ins ansetzen muss... ist doch eigentlich zu spezifisch für ersteres...+1
  • [KA18e] KA20: Im P2P die Herkömmlichen integrieren, davor nicht (Möglichkeit im P2P, Plattformen zu blacklisten)
  • Gibt's noch was ?
    • das umfasst zumindest momentan das Thema der Diskussion, soweit ich das sehe.
      
      
• [KA19] Zur Klärung des Sachverhalts wär's auch nützlich, mal zu begutachten, wie Diskussionssysteme die eine Implementierung herkömmlicher öffentlicher Kommunikationsmittel fest einplanen, diese Implementierung praktisch und konkret ausgestaltet haben; siehe wiki9999 und Architecture for democracy 2.0?, MakeYourLaws?, InterMix.org, branch?
  • +1+1+1(aber wer?+1)+1
  • Konsens, aber nicht eilig
    
    
• [KA20] Zu Zeiten der zentralen Datenbasis entscheiden wir nach festgelegten Kriterien, welche Plugins Schreibzugriff bekommen und welche nur Lesezugriff. Wenn wir auf P2P umsteigen, öffnen wir die Plattform aus technischen (Kontrolle nicht mehr möglich) und ideellen Gründen (Offenheit). Dabei soll auf eine der KA1b ähnliche Lösung gesetzt werden, damit die Öffnung keinem Diskussionssystem schadet und trotzdem die Vorteile der Offenheit ausgenutzt werden können.
  • Erledigt nach aktuellem Verständnis? +1+1+1+1+1+1
  • +1+1
  • Mit Diskussionssystemen meine ich ausdrücklich alle Systeme, in denen man diskutieren kann, also auch die Herkömmlichen.
  • Genauere Beschreibung auch in den Standpunkten von bloxx und ntroPi.
  • Trifft zu, wenn KA21.
  • +- 0 Ich hab' irgendwie den Eindruck, dass die Begrifflichkeit nicht passt; wann immer "Plug-In" gesagt wird, bezieht man sich ausschließlich auf den Kontext "Diskussionssystem im Rahmen des Meta-Diskussionssystems d!sco"; was man also ausschließt sind Diskussionssysteme auf Basis der Common Discussion Ontology, die aber nicht im Meta-Diskussionssystem d!sco eingesetzt sind, sondern außerhalb von diesem stehen. Sie teilen sich zwar Daten und Nutzer, als Nutzer eines solchen außenstehenden Diskussionssystems auf Basis der Common Discussion Ontology erlebt man allerdings nicht dieses "Nebenher der Diskussionssysteme", das man in d!sco erlebt. Man sieht nicht, wie eine Diskussion in anderen Diskussionssystemen aussieht, man sieht die Diskussion nur über das außenstehende Diskussionssystem auf Basis der Common Diskussion Ontology und vernimmt mehr Nutzer und Daten, das ist alles. Also, insofern: Weil bei KA20 die Rede von Plug-Ins ist, muss ich in Reflexion zu KA20 mitsamt ihrer Implikationen und verweise auf vorherige KAs die KA20 verneinen; wäre in dieser die Rede von Diskussionssystemen statt Plug-Ins, hätte ich sie bejaht.
    • Ich hatte mir das so vorgestellt, dass man ein außenstehendes Diskussionssystem leicht zu einem Plugin anreichern kann, so dass es mit d!sco kommunizieren kann. Ob man das Nebeneinander erlebt hängt eher davon ab in welchem Maße das Diskussionssystem Daten von d!sco übernimmt und anzeigt.+1
    • Nix dagegen hier Plugin durch Diskussionssystem zu ersetzen.
    • Ja, nach Slashs Definition gäbe es ja auch keine Plugins mehr (kann ich "Plattform" nehmen, ist kürzer und übersichtlicher)?
      • Von mir aus ja, aber Slash wünscht sich da vermutlich den exakten Begriff. Das würde dann z.B. Foren und Mailinglisten ausschließen, was in einem P2P Modell mit beliebig ausschließbaren Datenquellen je nach Plattformpräferenz eine nicht nötige Einschränkung wäre.
      • zumindest nach slashs Definition. Habe meine für diese Kernaussage angehängt.
      • Im Ersten Satz steht noch Plugin ... hier wäre aber tatsächlich Diskussionssystem nach Slashs Definition wünschenswert, da die Zentrale Datenbank nicht zugemüllt werden soll.
      • Nein, das ist so richtig: Ich schreibe ja, dass wir entscheiden, welche Plugins Schreibzugriff bekommen. Das wären slashs Diskussionssysteme. Die anderen Plugins haben halt nur Lesezugriff.
      • Find ich gut. Kannst ja die [KA12*] an der Stelle erwähnen.
        
        
• [KA21] In einem P2P ist es möglich, dass Plugin A die Daten von Plugin B nutzt, ohne, dass B auch die von A nutzen muss.
  • Erledigt da P2P als Ziel beschlossen ist? +1+1+1(B "muss" doch sowieso nicht!? falls keine Filtermögl.)+1+1
  • +1+1
  • +1 Ja, nutzen schon, aber das heißt nicht, dass Plug-In B gänzlich unbeeinflusst von Plug-In A ist; das "Nebenher" im Rahmen von d!sco wirkt auch
    • Damit wollte ich sagen, dass ein Forum die Daten von X-Tree-M nutzen kann, ohne dass dieses die Daten des Forums nutzen muss.
    • Wenn ich X-Tree-M richtig als Orientierungshilfe für die gesamte Diskussionslandschaft verstehe, dann wäre dies sehr hilfreich! Führt natürlich auf die Unterscheidung, ob der Initiator einer neuen Diskussion sich an ein dort vorhandenes Topic "andockt" oder ein eigenes Topic kreiert...
    • Eine zusätzliche "zentrale" Datenbank in der die hochwertigsten Diskussionssysteme zusammengefasst werden und die von verschiedenen Plugins angezeigt werden kann könnte einen gewissen Mehrwert bieten. Ergibt sich aber evtl. von selbst indem mehrere Diskussionssysteme voneinander alle Daten übernemen. Einziger Unterschied wäre, dass die Nutzer nicht von den Diskussionssystemen geteilt werden wie es zwischen Plugins möglich wäre.+1
      • Unser d!sco wäre also ein Hoster für die Daten hochwertiger Plattformen, der ins P2P integriert ist.
  • [KA21a]  Eine Möglichkeit zur Umsetzung wäre KA20.
    • +1 +1 Die grundätzliche dort skizzierte Idee ist schon ganz gut, legitimiert allerdings nicht Implementierung herkömmlicher Plattformen in das Meta-Diskussionssystem d!sco bzw. löst damit einhergehende Probleme erheblich.
      • Versteh nicht ganz. Im P2P ruft eine Plattform die Daten direkt nach ebenso gesendeten Filterkriterien vom Speicherserver der jeweiligen Plattform ab. Das geschieht für alle Plattformen, von denen die Plattform Daten abrufen will.
      • "Legitimierung" können wir in einem P2P nicht mehr selbst definieren. Da sind wir nicht mehr die Zentrale.
  • [KA21b] Einem Plugin die in KA21 beschriebene Freiheit zu lassen ist lohnend.
    • +1+1+1
  • [KA21c] Es ist notwendig, einem Plugin die in KA21 beschriebene Freiheit zu lassen.
    • +1
    • +1, um die schon erwähnten "Geschwafel" Bedenken zu lösen.
  • [KA21d] Zu dieser Freiheit gehört auch, dass keine Plattform davon abgehalten wird, von einer anderen Plattform Daten zu beziehen. (z.B. vom Forum)
    • +1
    • -1, davon abgehalten wird ja keiner, es wird maximal nicht aktiv unterstützt. Jedes Tool kann mit dem Forumbetreiber Daten austauschen ohne, dass wir das auch nur merken.
      
      
• [KA22] Es geht uns nicht nur um die Optimierung pirateninterner Diskussionen, sondern um Diskussionen allgemein (Politik).
  • +1+1+1++1+10+1+1
  • KONSENS
    
    
• :-)
  
  
  
  

2) Standpunkte einzelner User

• Merkbefreiter: 
  • [KA1] Wir sollten die Nutzer dort abholen, wo sie sich befinden. Denn nur dort findet augenblicklich der Diskurs im Internet statt.
  • [KA1.1] Das ist mMn in den Social Media Plattformen wie Foren, Mailinglisten, Twitter, Facebook & Co., Blogs, Nachrichtenportalen der Fall
  • [KA2] Wir sollten das Defizit aktueller Diskussionssysteme beheben.
  • [KA2.1] Das ist mMn die fehlende Übernahme unstrukturierter Diskussionsdaten aus den Social Media Plattformen.
  • [KA3] Wir brauchen einen Kriterienkatalog zur Bewertung ob ein System ein Diskussionssystem ist.
    • [KA3.1] Das macht es mMn auch zwingend notwendig über die Abgrenzung zwischen Informations- und Diskussionssystem detaillierter nachzudenken.
  • [KA4] Wir sollten weiterhin rein pragmatisch vorgehen und
    • [KA4.1] einen Schritt nach dem anderen machen
    • [KA4.2] die Probleme lösen, welche jetzt vorliegen
    • [KA4.3] dabei nicht die Grundidee aus dem Auge verlieren
• flow: [K4] Käse, da keine Frage von Zensur, sondern der Flexibilität. RSS ist ein gutes Vorbild
• DerThomas : Es gab einen harten Bruch mit dem herkömmlichen Post-System. Statt auf Rohrpost zu setzen (als "sanfte" Entwicklung), hat man auf Email gesetzt und offenbar gewonnen. Gleiches gilt für das Telefon, das Auto, das Flugzeug, ... . Manchmal gehört einfach Mut und Standhaftigkeit dazu, wenn man etwas revolutionär Neues vorhat.
  • Aber die ersten Automobiele sahen aus wie Kutschen, oder?
    • Um das Beispiel tot zu "reiten": Aber warum hat man nicht als Zwischenschritt die Pferde dran gelassen und die Kutsche nur um den Motor erweitert? :-D
• /: Dass man die User da abholen muss, wo sie sind, muss ich so, wie's wohl letztendlich im Gesamtkontext gemeint ist, verneinen. Es ist wichtig, Plug-Ins für User so einfach wie möglich auszugestalten. Natürlich muss man auch irgendwie 'ne Brücke dorthin schlagen, wo die User sind; schließlich muss man ja zusehen, dass die User was von der neuen Plattform mitbekommen. Dieser Brückenschlag ist allerdings durch Link-Verbreitung vollkommen hinreichend getan; um die User wirksam abzuholen, wo sie sind, muss der Brückenschlag nicht so stark ausgebildet werden, dass die herkömmliche Struktur in d!sco hineinwächst. Neue Strukturen werden auch dann von der Masse angenommen, wenn sie mit herkömmlichen öffentlichen Kommunikationsmitteln grundlegend brechen, sofern sie denn klar besser sind - siehe Fulleren's Kandidatenportal, das das Wiki-Kandidatenportal im laufenden Betrieb ausgestochen hat. Die erwogene Maßnahme, herkömmliche öffentliche Strukturen in d!sco zu implementieren halte ich für destruktiv, unnötig, und zu unzureichend definiert, um sie gutzuheißen. Ich stimme dem zu, dass wir wohl eingehender definieren sollten, was ein Diskussionssystem ist.
• bloxx: (Motto "let's filter")
  • Wahrgenommener Konsens:
    • Es wird auch ohne Herkömmliche Müll für andere Plattformen produziert. [KA8]
    • Es muss auf jeden Fall umfangreiche und schnelle Filtermöglichkeiten geben.
  • Meine weitere Meinung: KA20
    • Aufgrund beschränkter Möglichkeiten sollten wir zu Zeiten der zentralen Datenbasis als Moderatoren nach Kriterien auswählen, welche Plattformen Schreibzugriff bekommen und welche nur Lesezugriff.
    • Wegen mangelnder Offenheit, sollten wir schnell zu P2P umsteigen.
    • Weil manche Plattformen auch von unstrukturierten Diskussionen profitieren können und wir bei P2P keine Kontrolle mehr durchsetzen können, steigen wir dann für P2P auf folgende Lösung um:
      • Jedes Plugin ist für das Speichern und Filtern der selbst erzeugten Daten verantwortlich.+1+1
      • Ein Plugin, das also Daten von einem anderen abfragt, übergibt ihm einige Kriterien in Form eines Filterprotokolls, was für Daten er bekommen will.+1
      • Das Plugin tut das für alle ihm bekannten P2P-Server abzüglich der gebannten. Es findet keine Speicherung der abgefragten Daten statt.??
      • So kann jedes Plugin selbst bestimmen, mit welchen Plugins es zusammenarbeitet.+1+1+1
      • Manche Plugins wie "Twitter" werden so sicherlich isoliert, weil ihre Daten unbrauchbar sind. Das ist ganz im Sinne des Systems.+1 Sobald aber ein Plugin mit Twitter zusammenarbeitet, zeigt sich der Nutzen dieser Methode.+1+1+1
      • Außerdem wird Twitter nach mehr Integration streben und sein Plugin dafür optimieren.+1??
      • In einem P2P-Netzwerk kann "Müll" nicht die Server überlasten, höchstens den des müllproduzierenden Plugins.((naja, von falsch gesetzten Filtern abgesehen...))
    • Semantische Lücken lassen sich ohne großen Aufwand herausfiltern.
      • So kann der qKonsens alle Posts ausblenden, die nicht vom Typ "Quintessence" sind oder die mehr als 250 Zeichen haben.
      • Wenn X-Tree-M z.B. nur klar Themen zugeordnete Posts, die nicht länger als 1000 Zeichen sind, haben möchte, no problem: let's filter.
      • Wo liegt also das Problem?
        • Möglicherweise in der Angst, dass einem eine Plattform aufgedrängt wird oder die Serverlast steigt. Lösung: KA20.
        • Ich sehe da ein prinzipielles Problem! Wenn ich als qKonsens(-Nutzer) alle Posts mit mehr als 250 Zeichen automatisch ausblende, dann fehlt mir vermutlich wesentlicher Inhalt.(Siehe die beiden Transfer-Beispiele in der Anmerkung zu KA8a.b, ~Zeile 300!) Ich kann ja nicht voraussetzen, dass die Verdichtung des "Wesentlichen" auf 250 Zeichen schon realsiert ist. Vermutlich müsste im qKonsens eine "Import-Station" eingerichtet werden, die solchen formalen Beschränkungen nicht unterliegt. Das sollte doch ziemlich einfach machbar sein;( vielleicht nur temporär nutzbar). Dann wäre der Transfer ein ganz normaler Stationsübergang.   Und so ähnlich sollten wohl alle Plugins arbeiten... +1, das ist eine gute Lösung und das kann ja jedes Plugin so halten wie es am besten passt.
• ntroPi: pro KA20, KA1a/b
  • d!sco als Interface/Protokoll mit Auswahlmöglichkeit von welchen Plugins Daten kommen sollen.
  • Damit wäre die Gefahr durch zu geschwätzige Plugins oder falsche Strukturierung gebannt.
  • Mail, Forum, Wiki Plugins für beliebige Plattformen wären kein Problem. Ob sie je von anderen Pugins genutzt werden is eine andere Frage.
  • Hmm wenn ich hier Protokoll, statt Interface gesagt hätte, wäre das evtl. klarer gewesen. Ich sehe mal beides als mögliche Varianten ohne jetzt in den Details wühlen zu wollen.
  • Worum es mir geht ist, dass Plugins einzeln untereinander Daten austauschen können ohne, dass eine zentrale Datenbank (egal ob auf Server oder P2P) involviert sein muss (aber kann).+1
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

====

/ - ich integrier' morgen und dampf dabei runter; das sind erst mal alle meine Gedanken: und meine Kommentare/Anmerkungen dazu, meine auch.meine auch.

• [KA13]
  • Belege*:
    • Grundidee:
      • Problemstellung: Ziel ist, den Willensbildungsprozess(!) mithilfe technischer Unterstützung für eine beliebig große Anzahl von Teilnehmern zu öffnen
      • Globaler Lösungsansatz:
        • (Optimal aufbereitete Information verkürzt die notwendige Diskussion) und eine effiziente Diskussion vereinfacht dabei den Entscheidungsprozess.
        • ~ Ziel: Qualitativ bessere Kommunikation; Förderung kollektiver Intelligenz
      • Framework des Diskussionssystems: Technisch wollen wir eine Grundstruktur (Framework) schaffen, auf der die unterschiedlichen MFT-Gruppen ihren Prototypen als Plug-In aufsetzen.
      • Plug-Ins: Voraussetzung ist, dass das jeweilige Plug-In einen Migrationspfad, z.B. in Form einer Ontologie anbietet, damit die Plug-Ins untereinander die Daten austauschen können.
      • Vorteile dieses selbstlernenden Systems:
        • Die Diskussion, was das beste MFT ist, wird ersetzt durch einen freien Wettbewerb unterschiedlicher MFTs (Plug-Ins), die sich ihre Daten teilen.
        • Dadurch ensteht ein selbst-lernendes System, bei dem die Benutzer in Zukunft einen Mix aus denjenigen MFT (Plug-Ins) verwenden werden, die sich aus der Praxis heraus als sinnvoll ergeben haben, ohne dass die Entwickler des Diskussionssystems heute wissen müssen, wie dieser Mix aussehen wird.
        • Der Benutzer kann zwischen den unterschiedlichen Diskussionsmethoden/MFTs hin und her-wechseln und in der Praxis erproben, welches MFT ihm mehr zusagt
        • Die Entwickler eines MFTs bekommen auch Input aus anderen MFT Communities.
        • Alle MFTs können auf die Daten der anderen MFT zugreifen, so dass verschiedene Lösungsstrategien für das Problem der Willensbildung parallel entwickelt und getestet werden können. 
• Was ist mir wichtig: Dass in ein Meta-Diskussionssystem ausschließlich Diskussionssysteme aufgenommen werden.
• Was ist meine größte Angst: Dass die Vermischung von Diskussionssystemen und herkömmlichen öffentlichen Kommunikationsmitteln bezgl. d!sco dessen Gesamtqualität als Diskussionssystem, das sich qualitativ klar von herkömmlichen öffentlichen Kommunikationsmitteln abgrenzt, zunichte macht.
  
  
• Konzeptkritik:
  • d!sco hat 2 systemische Schwächen:
    • 1. Je einzigartiger ein integriertes Diskussionssystem im Verhältnis zu den anderen integrierten Diskussionssystemen im Rahmen von d!sco ist, desto weniger profitiert es verhältnismäßig von den anderen integrierten Diskussionssystemen
      • Da hast du Recht. Aber immer noch besser als gar nicht zu profitieren oder?
        • Profitieren tun einzigartige Diskussionssysteme definitiv auch; ähnliche Diskussionssysteme profitieren im Rahmen von d!sco jedoch deutlich mehr
          • Dafür sind ähnliche Systeme auch austauschbarer und somit schnell überflüssig. Das wird durch d!sco vielleicht noch etwas verstärkt aber ich sehe hier keinen Nachteil durch unseren Ansatz, im Gegenteil wird der Wettbewerb verstärkt da Redundante Systeme schmerzlos entfernt werden können.
      • Das kann man auch "andersrum" sehen. Wenn ein "einzigartiges" Diskussionssystem einigermaßen plausibel mit seinen Stärken dargestellt ist, dann wird es Anziehungskraft auf alle ausüben, die an die Grenzen "ihres" Diskussionssystems stoßen. ((Allerdings: was heißt hier "profitiert"?))
    • 2. Jedes öffentliche Kommunikationsmittel erzeugt durch die spezifische Weise, wie es einer Diskussion Rahmenbedingungen setzt, einen Diskussionsbestand mit einer ganz spezifischen Qualität; knapp gesagt: öffentl. Kommunikationsmittel A => A-Diskussionsbestand; öffentl. Kommunikationsmittel B => B-Diskussionsbestand
      • Ganz konkretes Beispiel: ML-Diskussion => Hang zu Off-Topic
      • Wenn man ein öffentliches Kommunikationsmittel mit einem anderen vernetzt, wie wir das mit Diskussionssystemen vorhaben, dann vermischt sich auch die Qualität des Diskussionsbestands; knapp gesagt: öffentl. Kommunikationsmittelverbund A-B => A-B-Diskussionsbestand
      • Es kommt also eine andere Qualität eines Diskussionsstands in ein öffentliches Kommunikationsmittel rein, als sie normalerweise aus ihm selbst heraus entstehen würde.
        • Es ist davon auszugehen, dass die öffentlichen Kommunikationsmittel im Rahmen von d!sco nie alle gleich gut sein werden
        • Wenn die öffentlichen Kommunikationsmittel unterschiedlich gut sind, dann wird es immer ein Kommunikationsmittel geben, das sich qualitativ raufziehen lässt und eines, das qualitativ runtergezogen wird (??)
          • Wenn das hochwertige selbst wählen kann von welchen anderen KMitteln es Daten bezieht sollte zumindest das Problem des runterziehens geringer sein. [KA1a/b]
          • Aus dieser systemischen Schwäche für bessere öffentliche Kommunikationsmittel ist als Konsequenz zu ziehen, dass man verstärkt im Rahmen von d!sco Strukturen schafft, die die Weiterentwicklung jedes einzelnen Tools fördern, so dass sich die Gesamtqualität dieses öffentl. Kommunikationsmittelverbunds beschleunigt erhöht
            • denn dadurch würden die Qualitätsgefälle dann relativ verringert werden, die ja für die besseren öffentlichen Kommunikationsmittel im Rahmen von d!sco nachteilhaft sind [/Gedankengang] YAY ! :D meine Güte, ey...
            • herkömmliche öffentliche Kommunikationsmittel sind qualitativ weit abgeschlagen von Diskussionssystemen; die Aufnahme von herkömmlichen öffentlichen Kommunikationsmitteln ist also genau das Gegenteil von dem, wie wir mit dieser 2. Schwäche am besten umzugehen haben (??)
              
              
• Was ich praktisch nicht sehe ist ein Mehrwert zu Copy & Paste, falls man, wie angedacht, ML/Forum/Newsgroup nicht als plug-in, sondern als Andock-Element in d!sco integriert. Diese Ausführung müsste sich an Copy & Paste messen lassen, und pragmatisch so viel attraktiver als C & P sein, dass die Leute nicht C & P machen, sondern stattdessen sich in d!sco begeben und sich dem Andock-Element zuwenden.
  • so lange nicht plausibel und anschaulich dargelegt werden kann, inwiefern das Andock-Element gegenüber C & P einen erheblichen praktischen Mehrwert hat, ist das Andock-Element unnütz und wird von niemandem genutzt+1
    • dafür kann der PoC ja genutzt werden, um genau solche Fragen zu beantworten.
    • Wie weiter oben beschrieben: C & P ist stupide Sklavenarbeit, Optimieren eines Inhalts während der Diskussion ist ein inhaltlicher Beitrag. Das werden viel mehr Leute tun. (Und ich hatte immer gedacht, C&P ist eine Möglichkeit, die unvermeidliche Sklavenarbeit rasch hinter sich zu bringen, um rasch zur kreativen Tätigkeit zurückkehren zu können ;-) ...
      
      
      
      

III) Kernaussagen Bewertungen Übersicht [KA#]: +-Wert/Anzahl Stimmen.
(Stand Abend 25.10.´13)

• [KA1]: +-0/7
  • [KA1a]: +2/2
  • [KA1b]: +2/2
• [KA2]: +-0/7
• [KA3]: -2/6
• [KA4]: -5/7
  • [KA4/2]: +-0/2
  • [KA4a]: -1/3
  • [KA4b]; -1/3
• [KA5]: +1/7
  • [KA5a]: -1/3
  • [KA5b]: -1/3
  • [KA5c]: 0/2
  • [KA5d]: -1/3
  • [KA5e]: -3/3
  • [KA5f]: -3/3
  • [KA5g]: -3/3
  • [KA5h]: -3/3
• [KA6]: -3/7
• [KA7]: +2/6
  • [KA7/2]: +2/2
• [KA8]: +5/5
  • [KA8a]: +3/3
  • [KA8a.b]: +3/3
  • [KA8b]: -2/4
• [KA9]: +-0/2
• [KA10]: +2/2
  • [KA10a]: +2/2
• [KA11]: +2/2
• [KA12]: +2/2
  • [KA12a]: -1/2
  • [KA12b]: +2/2
  • [KA12c]: -1/2
  • [KA12d]: +2/2
  • [KA12e]: +2/2
  • [KA12f]: +1/1
• [KA13]: +1/1
• [KA14]: +-0/2
• [KA15]: -2/2
• [KA16]: -1/1
• [KA20]: +2/2