Einheitliche Namen

[artnoveau]

Wie wollen wir dafür sorgen, dass einheitlich die selben Namen verwendet werden und keiner doppelt vor kommt, etc....?

[matthiasr]

personen werden primär über ihnen zugeordnete URLs (twitter, facebook-profil, blog etc.) identifiziert. wenn einer person eine url zugeordnet wird, die bereits einer anderen person zugeordnet ist, wird

a) eine mail an einen merge-beauftragten verschickt, der manuell verifiziert dass beide identisch sind oder b) ein "könnten zusammen gehören"-zähler wird inkrementiert, wenn eine gewisse schwelle überschritten ist GOTO a) (oder automatischer merge, aber damit lässt sich sehr viel schindluder treiben) oder c) später lässt sich das crowdsourcen an besonders "verdiente" user, die dann teil a) übernehmen.

[erlehmann]

Merge-Beauftragten, manuell identifizieren, crowd-sourcen, hahaha. Der Vorschlag ist unbrauchbar.

Ich würde vorschlagen, nichts zu tun, bis dieser Fall das erste Mal eintritt. Und dann entweder beide URLs zu streichen oder die Leute aufzufordern, einen spezifischen String über diese URL bereit zu stellen. Für Emails wäre etwa ein „Klicke diesen Link“ möglich.

[matthiasr]

"die leute auffordern", genau. der nutzer hat sich gefälligst deiner entwicklerdenke anzupassen!

[erlehmann]

Nunja, sollen sie sich besser deiner Entwicklerdenke anpassen? :D

[matthiasr]

"das geht so nicht, wir kümmern uns drum." vs. "das geht so nicht, mach unsere datenbank heile!"

[erlehmann]

Ich weiß nicht, wie man das machen kann. Aber deine Vorschläge muten mindestens komisch an und ich habe eine ganz starke Vermutung, dass sie nicht skalieren.

[matthiasr]

a) skaliert nicht, klar, sichert aber für den anfang erstmal konsistenz. c) ist der ansatz, den z.b. foursquare fährt, b) eine (teilweise) algorithmische lösung.

was du vorschlägst ist halt, das problem zu ignorieren. das skaliert auch nicht.

[erlehmann]

a) Machst du den Merge-Beauftragen? Dann wäre ich okeh damit :3 c) Mit Autorität zu argumentieren ist so discordianfishy … b) Welche Algorithmen denn? Ich denke, wir sollten Nutzerdaten und generierten Krams strengstens trennen.

[matthiasr]

eben einen merge erst in betracht zu ziehen, wenn er von mehreren seiten vorgeschlagen wird.

und "ist identisch" ist halt eine generierte relation, die die nutzerdaten direkt beeinflusst.

[erlehmann]

Plom fragt, ob du nun nicht den Merge-Beauftragten machen willst. Ich sekundiere dies auf das Härteste!

[matthiasr]

jaja, ist ja gut, ich mach's :)

[erlehmann]

Meinetwegen. Geschlossen wird es aber noch nicht, weil keine skalierbare Lösung.

[dridde]

Denkt auch an den anderen Fall, eine Person hat ja durchaus mehrere URL die sie identifizieren und auch Sachen wie ein Profil mit twitter-url und eins mit facebook müssen zusammfassbar sein. Also müsste man dem eintragenden User eine Auswahl an "ähnlichen Namen" oder bereits bestehenden Personen anbieten. Sollte eine URL doppelt sein würde ich schon davon ausgehen dass es die gleiche Person ist, wie sollst du sie sonst identifizieren? Ergo dann gleich die Bestehende nutzen, statt nachzufragen oder eine neue Anzulegen. Da ab und an zu bestimmten Sachen manuell draufzugucken ist aber sicher trotzdem nötig. Dass das nicht skaliert ist klar.

[erlehmann]

Wie wäre es denn, Personen einfach einem Nutzer zuzuordnen (wie Relationen)? Dann hätte man halt keinen globalen Namensraum.

Dem Problem, dass dann unter Umständen zwei gleiche Leute als unterschiedliche Knoten angezeigt werden, könnte man durch simple Heuristiken bzgl. Namen, URLs und (signifikanter) Beziehungen begegnen. Dem Nutzer würde dann bei Auswahl eines Filters schlicht eine Frage gestellt: „artnoveau und rtnoveau sind sich ähnlich. Handelt es sich möglicherweise um die gleiche Person?“ eine Bejahung würde beim filternden die Datensätze beider Knoten zu einer Person zusammenführen.

[dridde]

Da müsstest du dann konsequenterweise die Daten in der Datenbank aber auch zusammenführen. Vom schnellen überfliegen des Elixir-Tutorials konnte ich jetzt nicht ersehen, ob dass das ohne Aufwand kann. Und warum diese Heuristiken beim anzeigen und nicht beim eintragen?

Wo siehst du konkret den Vorteil, Personen und Nutzer zu trennen? Sollen denn nur Angemeldete und bekannte Nutzer überhaupt etwas eintragen können?

[erlehmann]

In der Datenbank zusammenführen ja — aber eben nur für den filternden Nutzer, bei dem dann eine Person entsteht, die alle Namen und URLs der vorherigen hat und auf die alle Beziehungen verweisen.

Heuristiken kannst du schwer beim Eintragen haben, wenn du die Welt vom Query her denken willst, aber dann eben noch keinen hast. Eine globale Zusammenführung widerspricht dieser Idee (auch: wenn der Nutzer lügt, belügt er nur sich selber und seine Verfolger, nicht alle).

Zur Trennung von Person und Nutzer habe ich bei #9 schon etwas geschrieben: https://github.com/erlehmann/fickileaks/issues#issue/9/comment/641874

[dridde]

las ich und beantwortete ich. Wenn ein eintragender Nutzer lügt, belügt er dennoch alle. Es kommen ja Daten, die alle sehen in die Datenbank. Über diese Daten kannst du eh nie die Aussage treffen, ob sie stimmen oder nicht. Nur gewichtet raten via Anzahl und Widersprüche etc. Die Abfrage soll eh für jeden durchführbar sein, nicht nur für Nutzer. Jedes mal bei der gleichen oder generell jeder Abfrage gefragt zu werden, ob diese Personen, die gleich scheinen, die gleichen sind, ist alles andere als Usability. Außerdem kann doch ein Nutzer der weder rtnoveau noch artnoveau kennt gar nicht beurteilen, ob es die gleiche Person ist und ist damit überfragt. Mal abgesehen von dem "wtf, wenn die das wissen, warum fragen die mich das?"-Erlebnis. Das ist so ein wenig "Open Source Software-Ideologie" in der Hinsicht, wir haben hier so eine Erkenntnistheorie, tja lieber Benutzer, da können wir jetzt auch nichts dafür, handle mit es. Aber in dem Falle ist es unser Job, dafür eine Lösung anzubieten.

Neu! Jetzt diese Antwort als Kopierpaste unter der anderen!

[erlehmann]

Nochmal: Wenn ein eintragender Nutzer lügt, lügt er nicht alle an, sondern die, die ihm/ihr folgen, sehr wahrscheinlich unter Anderem sich selbst. Würde man nun (gewichtet) raten, vermischt man die Meinungsebene mit generiertem Blabla; das ist ein klarer Kategorienfehler.

Die Abfrage kann ruhig für jeden durchführbar sein — dann speichern wir Identitätsbehauptungen halt im localStorage und übernehmen sie evtl., sobald ein Benutzerzugang angelegt wird.

Deinen Kommentar zu Erkenntnistheorie und Open Source verstehe ich vermutlich nicht. Was willst du „lösen“, das 4000 Jahre Philosophiegeschichte nicht schafften?

[erlehmann]

möglicherweise relevante Diskussion zwischen erlehmann und dridde http://2pktfkt.de/irc/nodrama.de/2010-12-30.html#108

[matthiasr]

Frage: wie wollt ihr mit getrennten Benutzern/Personen die Funktion "X leugnet dies" bzw. "X bestätigt dies" einbauen? Muss dann Geraldine alles einzeln leugnen oder bestätigen, was jemals jemand über irgend eines ihrer vielen "Person"-Objekte gedacht hat?

Ich hatte mir ein simpleres Modell vorgestellt: Es gibt Personen. Personen entstehen, in dem sich jemand anmeldet oder jemand etwas über sie einträgt (etwa eine URL). Wenn sich eine von jemand anderem eingetragene Person anmeldet muss sie auf geeignete Weise nachweisen, dass ihr die (eine der) ihr zugeordneten URLs gehört/-en, dann bekommt sie Zugangsdaten. Fertig.

[erlehmann]

Na ganz einfach: Benutzer α meint, dass Personen a und b nichts miteinander haben. Wenn Benutzer β dann Benutzer α abonniert (boniert, hihi) hat, sieht er das in seinem Graphen. Da die vielen Person-Objekte anderen Leuten gehören, müsste Geraldine wohl jeden Einzelnen beschlafen, um sie zur Rücknahme der Behauptungen zu bringen.

Die Existenz von Benutzern kann überprüft werden. Die Existenz von zu Knoten in der Datenbank äquivalenten Personen zu überprüfen, berührt die ursprüngliche Wissensfrage.

[matthiasr]

D.h. aus "X leugnet das" wird "irgend jemand leugnet das". Und am Ende ist das ganze zwar theoretisch schön, aber enthält keinerlei verwertbare Information.

[erlehmann]

Wieso? Wir haben dann „Benutzer matthiasr meint, dass Person A leugnet, etwas mit Person B zu haben.“. Was ist daran denn bitte nicht brauchbar?

[matthiasr]

Das ist nicht das selbe. Die Information, was eineR der Beteiligten dazu sagt hat einen ganz anderen (unabhängig zu bewertenden) Stellenwert als eine Aussage von Dritten darüber. Und genau diese Unterscheidung willst du wegwerfen.

[erlehmann]

Benutzer matthiasr kann ja gerne der Meinung sein, dass Person A zur URL http://dach33.de/ gehört und Person B zur URL http://twitter.com/bangpowwww. Alles über diese Ebene hinausgehende hätte einen Wissensanspruch und das wird spätestens dann problematisch, wenn du Dinge über meine imaginäre (na?) Exfreundin meinen möchtest.

[matthiasr]

Benutzer matthiasr weiß und kann beweisen, dass http://rampke.de/ und http://twitter.com/matthiasr zu ihm gehören.

Kein Wunder, dass die Philosophie es in 5000 Jahren nicht geschafft hat Ergebnisse hervorzubringen.

[erlehmann]

Steile These, Kumpan. Ich glaube an laufenden Code, also bau doch mal einen Prototypen für das Zeug mit den URLs, der mit http://creativecommons.org/about/people#michellethorne oder https://secure.wikimedia.org/wikipedia/en/wiki/Michelle_Thorne_%28Creative_Commons%29 funktioniert.

Das Problem der Intersubjektivität von Wissen mal außen vor gelassen: Kann Benutzer matthiasr denn nun auch nachweisen, dass er mit Person M „gemeint“ ist? Welche Konsequenzen hätte dies für die Knoten im Graph?

Im Übrigen bitte ich um Verzeihung für meine mangelhaften philosophischen Leistungen in den letzten 5000 Jahren, mein ADS wurde erst Oktober letzten Jahren diagnostiziert.

[erlehmann]

Gelöst über automagische Korellation von URLs und Queryöffentlichkeit. Vielen Dank an dieser Stelle an dridde und fengor.