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

[pa.rei AT gmx.de]

Hi Marc,

tja, so ganz weiß ich nicht. Du sagst ja,

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

Heißt das, dass es nicht mehr möglich wäre, dass zwei sich völlig Fremde aus 
dem Kreise Jedermann nicht die Möglichkeit hätten, parallel widersprüchliche 
Referenzen/Markierungen zu machen? Siehst du da auch eine Schizophrenie?
Wenn so etwas ungewollt auftritt, könnte das Tool doch einfach die ältere 
Referenz verwenden, um einen Constraint zu "simulieren" - oder übersehe ich 
etwas?

Grüße,
Paul

> Gesendet: Montag, 21. Juli 2014 um 18:39 Uhr
> Von: marc <marc AT merkstduwas.de>
> An: ag-meinungsfindungstool AT lists.piratenpartei.de
> Betreff: [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