Wie sieht unser Datenbankmodell aus?

[erlehmann]

_Personen_: eine ID, viele Namen, viele URLs, ein Zeitstempel (wann angelegt)

_Namen_: ein Namensstring, viele Personen, ein Zeitstempel (wann angelegt)

_URLs_: ein URL-String, viele Personen, ein Zeitstempel (wann angelegt)

_Beziehungen_: eine ID, einen Typ (String „FUCK“ oder „KISS“), eine beliebige Anzahl an Personen, ein Zeitstempel (wann angelegt), einen Benutzer (der behauptet, dass es die Beziehung gibt)

_Benutzer_: eine ID, ein Passwort, eine Email-Adresse, viele Personen, viele Beziehungen

[dridde]

Na so denke ich mal nicht. Ein Benutzer ist ja auch ne Person, da brauchst du keine zwei Relationen für. Und Beziehungen sollten wir festlegen was die können sollen (das da oben geht schon in die Richtung) und dann eben gucken wie wir das datenbanktechnisch abbilden. Aber "N Endpunkte" meint dann ja, eine Beziehung besteht zwischen N Personen. Wenn du das so handhaben willst, bräuchten wir eine Beziehnungsrelation und n paar Zwischenrelationen, für Wünscher und Beteiligten. Das wäre so sehr trivial umzusetzen und so vom ersten durchdenken her auch ganz gut gefiltert nach Beziehungen von einzelnen Personen abfragen. Für die Wünscher müssten wir gucken, ob es wichtig ist, wer sich das wünscht, da uns für die Darstellung ja nur der Wunsch/Vermutungscount interessiert. Ggf fahren wir da besser, also performanter das an der Beziehnug mitzuspeichern als das für jede im Graph sichtbare Beziehnung aufsummieren zu müssen.

[erlehmann]

Ein Benutzer ist nur unter großen Schwierigkeiten als identisch mit einer Person zu setzen. Wir haben da schlicht Probleme mit der dahinterliegenden theoretischen Philosophie.

Ist ein Nutzer keine Person, haben wir keinen Eingriff von der realen in die Meinungsebene. Kann ein Nutzer eine Person sein, müssen wir Wissen (ugs. „gerechtfertigte wahre Meinung“) zumindest teilweise begründen und insbesondere mit der Realität synchronisieren — z.B. sehen, dass wir Gettier-Probleme https://secure.wikimedia.org/wikipedia/de/wiki/Gettier-Problem vermeiden.

Mal abgesehen davon, dass wir Verfahren bräuchten, beliebige URLs zu claimen. Bei Email geht das. Bei Web-Adressen? Viel Spaß mit Wikipedia-Artikeln.

[dridde]

Die Vermischung der realen und der Meinungsebene hast du doch eh, da die Personen real sind. Nur die Beziehnungen und die Relationen zwischen Beziehnungen und Personen sind Meinungsebene. Das die Personen real sind, soll doch gerade die URL-Geschichte (die nicht von mir stammt) verifizieren. Was spricht dagegen, aus einer Person einen Nutzer werden zu lassen. Das einzige wäre, dass sich "bernd" nicht als Person "eisenhower" anmeldet und somit "verifizierte" Verbindungen für eisenhower - weil selbst eingetragen - erstellt. Wenn du Nutzer und Personen dann trennst, kannst du aber eben nicht konkrete Gegendarstellungen von Nutzern auf Personen mappen, wie "eisenhower besteitet diese Verbindung". Weil du spätestens dort Nutzer und Person mappen müsstest, oder nicht? Ich sehe dein Problem zwar, aber das ist grundsätzlicher als die Frage, an Person mailaddy und pw-Felder dranzupappen oder extra Nutzerentities zu haben.

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.

[erlehmann]

Nein, eine „Person“ in der Datenbank ist nicht eine „reale Person“ — im besten Fall ist es ein (komplizierter) Zeiger auf eine reale Person.

Was dagegen spricht, Personen und Benutzer zu vereinen, sind zwei Unmöglichkeiten. Erstens können wir Rechtfertigungen nicht auf Stichhaltigkeit überprüfen. Zweitens können wir die Wahrheit von Aussagen, insbesondere Aussagen der Art „Person A entspricht Benutzer α“ nicht mit der Repräsentation dieser Aussagen in der Datenbank abgleichen.

Gegendarstellungen von Nutzern können wir doch immer noch haben — als eine Liste von „deniers“; eine beispielhafte Proposition wäre dann „Nutzer eisenhower bestreitet, dass Sascha Lobo http://saschalobo.com mit Kathrin Passig http://kathrinpassig.kulturindustrie.com/ ein Buch geschrieben hat.“.

[erlehmann]

Angepasst.