Re: [Ag Meinungsfindungstool] ReferenceType Constraints (war - Re:Workflows)

["Schallehn AT t-online.de" <Schallehn AT t-online.de>]

Haallo Freunde,
habt ihr euch hier nicht ziemlich verlaufen??

Mal abgesehen davon, dass mir hier der Begriff "Workflow" vergewaltigt erscheint...

Es muss doch wohl unterschieden werden:

• ein Post ist "per se" Objection oder Agreement zu einem anderen Post - das sollte dann objektiv/unstrittig sein - aber genau das ist wohl das Problem ;-)
  oder aber
  
• ein Post ist als Objection oder Agreement zu einem anderen Post "gemeint" - dann ist das eindeutig Sache des Autors!

Für den qKonsens wäre es ein Komfortmerkmal, wenn Diskussionsbeiträge als PRO oder KONTRA zu bestimmten Kernaussagen deklariert werden könnten - und dazu schon in der Konsenskiste eine Markierung erscheint.

 

Die Frage ist doch: welche Funktionaltät steht dem Autor zur Verfügung, um solche Referenzen zu deklarieren? Wenn er nur per Radiobutton die Wahl zwischen PRO undd KONTRA hat, kann doch eigentlich nichts passieren?  Wobei ich durchaus in Betracht ziehen würde, dass der Autor (aber nur er/sie!) diese seine Meinung auch ändern kann. Z.B.: was heute als Schutz des Individuums gilt, kann morgen als Einschränkung der Freiheit gesehen werden - oder umgekehrt ...

 

Sorry für die Einmischung, wenn dies euch nicht hilft.

Viele Grüße!
Wolfgang

-----Original-Nachricht-----
Betreff: Re: [Ag Meinungsfindungstool] ReferenceType Constraints (war - Re:Workflows)
Datum: Mon, 21 Jul 2014 18:47:02 +0200
Von: "marc" <marc AT merkstduwas.de>
An: <ag-meinungsfindungstool AT lists.piratenpartei.de>

A2 müsste natürlich an P2 ReferredFrom P1 als "Disagreement" setzt

-----Original Message-----
From: marc
Sent: Monday, July 21, 2014 6:39 PM
To: ag-meinungsfindungstool AT lists.piratenpartei.de
Subject: [Ag Meinungsfindungstool] ReferenceType Constraints (war -
Re:Workflows)

Hi Paul,

Du schriebst:
> Was wäre zum Beispiel, wenn der eine Nutzer einer 'Agreement'-
> Referenz und der andere lieber eine 'Disagreement'-Referenz setzen
> möchte? Gewinnt dann der Schnellere?

Das wäre ja nur relevant für eine einzelne Referenz zwischen den selben
Posts (A ==> B), oder?

Hier kommt es mMn auf auf zwei Dinge an:

(1) den ReferenceType Constraint: Agreement & Disagreement können nicht zur
selben Zeit zwei Posts miteinander referenzieren
(2) die Autorisierung des Benutzers: ist die Berechtigungsebene für das
setzen von Refenrenzen Public, Group oder Author?

(Wobei natürlich die Berechtigung hier noch komplexer sein würden, wenn wir
zwischen Referenzen in ReferrsTo und ReferredFrom unterschieden.)

Also z.B. wenn der Post P1 vom Autor A1 und der Post P2 vom Autor A2 jeweils
die Berechtigungsstufe "Author" zum setzen von Referenzen haben, dann könnte
A1 an P1 RefersTo P2 die Referenz als "Agreement" setzen, während A2 an P2
RefersTo P1 als "Disagreement" setzt.

Das kann durchaus eine gewünschte Semantik besitzen, da die Referenzen von
unterschiedlichen Benutzern hinzugefügt wurde. Allerdings hätte
d!scoArguments mit der Darstellung dieses Sachverhaltes größere
Schwierigkeiten und müsste z.B. hier einen "Dissens" ausweisen. Das würde
also Deinem Ansatz entsprechen den Plug-Ins die Handhabung der
Inkonsistenzen zu überlassen.

> Rein logisch kann man sicher sagen, dass eine Aussage nicht
> gleichzeitig zustimmen und ablehnen kann (oder doch? Vielleicht
> enthält sie ja zwei widersprüchliche Aussagen...).

Wie eben angedeutet könnten die Plug-Ins eine Verletzung der Constraints als
"Dissens" auffassen. Das hätte doch auch was! Die Ontologie würde dann
Constraints "nur" pro Berechtigungsebene prüfen und durchsetzen. Den ein
Dissens bei einem einzelnen Autor wäre ja quasi der Diagnose Schizophrenie
gleichzusetzen.

D.h. meine Idee wäre es hier, sobald A1 versucht eine zweite Referenz an P1
RefersTo P2 als "Disagreement" zu setzen, lässt d!sco dies nicht zu und
wirft eine ConstraintViolationException oder ähnliches.

> Objection und
> Agreement sind schon schwerer - handelt es sich um Zustimmung,
> weil es sich um die bestvorgeschlagene Lösung handelt, aber da gibt
> es trotzdem noch Einwände? Ich glaube, solche Konflikte müssen
> Menschen in geeigneten Plug-ins (Clean-up Plugins?) versuchen zu
> lösen.

Auch wieder ein Fall für den "Dissens", welcher über die d!sco Plug-Ins
ausgewiesen werden könnte. Hier ein spezielles Dissens-Lösungs-Plug-In
anzubieten ist glaube ich nicht notwendig, da man auch problemlos eines der
vorhandenen Plug-Ins genau zu diesem Zweck einsetzen könnte. Hier wäre es
nur "nett" und hilfreich (sprich benutzerfreundlich), wenn aus dem Dissens
ausweisende Plug-In bereits über die "d!sco Frame Bar" der Dissens in ein
anderes (oder dasselbe) Plug-In als neuer Diskurs übernommen werden könnte.

> Wenn die auszuschließenden Kombinationen so viele werden, dass
> man eine Tabelle dafür braucht, sollten wir uns vermutlich fragen,
> wie wir das semantisch besser darstellen können. Es ist ja nicht so
> zuträglich für eine Ontologie, hunderte intransparente
> Einschränkungen zu haben.

Volle Zustimmung! Wir sollten versuchen die Komplexität der Bedingungen und
Abhängigkeiten so gering wie möglich und damit die Semantik der Ontologie
maximal verständlich bis intuitiv zu halten. Aber ich befürchte, dass wir
sie nicht auf Null werden reduzieren können.

> Als erstes müssten wir wohl die Begriffe schärfen, wenn ein
> Computer damit umgehen und Inkonsistenzen finden soll. Wo
> genau liegt der feine Unterschied zwischen 'Objection' und
> 'Disagreement' (Einwand und Ablehnung, es gibt natürlich den
> Unterschied)?

Yupp. Ich glaube auch wir müssen die Semantik weiter ausdefinieren und uns
über die Begriffe verständigen. Wird mal wieder Zeit unser Vokabelheft
herauszuholen: https://meinungsfindungstool.piratenpad.de/Definitionen
Ziemlich unübersichtlich. Besser wir machen ein neues Pad auf für die
Definition jedes einzelnen Begriffes der Ontologie auf, oder?

> Oder sollten wir den Umgang mit Inkonsistenzen den Tools
> überlassen? Ein ReferenceType-Rating einführen?

ReferenceType-Rating bräuchte ich jetzt nicht unbedingt. Aber die Tools
sollten außerhalb der Berechtigungsebene den Dissens individuell handhaben.
Also jeweils innerhalb der Berechtigungen Public (jedermann), Group
(Mitglieder der Gruppe) oder Autor (nur der Ersteller) sollten wir mMn die
Einhaltung der Constraints über die d!sco Implementierungen "erzwingen".

Cheers
Marc


--
Ag-meinungsfindungstool mailing list
Ag-meinungsfindungstool AT lists.piratenpartei.de
https://service.piratenpartei.de/listinfo/ag-meinungsfindungstool


--
Ag-meinungsfindungstool mailing list
Ag-meinungsfindungstool AT lists.piratenpartei.de
https://service.piratenpartei.de/listinfo/ag-meinungsfindungstool