BerndSchiffer: Zwei Dinge dazu.

Zum einen möchte ich Unterscheiden zwischen der Repräsentation und der Persistierung einer Seite. Wenn eine Seite mit der Knotenmetapher gesehen wird, dann ist das eine Repräsentation. Wie der Knoten tatsächlich verwaltet wird, also ob er als einzelne einfache Datei, als Index oder Datenbankeintrag oder sonstwie persistiert wird, ist letztlich unabhängig von der Repräsentation - ein Knotenobjekt kann aus allen Persistierungen rekonstruiert werden. Letztlich ist Knoten auch nur eine Abstraktion von beliebigen Entitäten in einem Wikisystem oder CMS (ich glaub Drupal macht das durchgängig mit Knoten).

Zum anderen ist das und gut is nicht wirklich so gut, denn Du schreibst führt eine liste über seine referenzen. Somit hat jeder Knoten Kenntnis von den Links, die auf ihn verweisen, und jeder Knoten kennt natürlich auch seine eigenen Links, die er auf andere Knoten hält. Abgesehen davon, dass diese doppelte Datenhaltung redundant und somit fehleranfällig und wartungsaufwändig ist: wenn Du einen Knoten umbenennst musst Du auch alle Knoten "anfassen", die auf den umzubenennenden Knoten verweisen, denn deren eigene Links müssen ja auch geändert werden. Ich sehe nicht, wie das einfacher sein soll als das, was ich oben schrieb. Mit einem einfachen Austauschen des Namens- oder Seitenknoten ist es jedenfalls so nicht getan. [nicht der namens-knoten wird ausgetauscht, sondern nur der name (der natürlich auch wieder nur ein zeiger auf den eigentlichen namen sein kann)]

SK-Genius: ich misch mich mal wieder ein, auch wenn mir bei den ganzen fachbegriffen ganz schwindlich geworden ist. ich fass es also nochmal so zusammen wie ich es verstanden habe:

sigi meint: man verwaltet alle links zwischen den seiten in ner extratabelle mit den spalten 'quelle' und 'ziehl', hierbei müsste man bei jeder änderung schaun welche links geändert wurden und die tabelle aktualisieren.

BerndSchiffer meint: auf diese tabelle kann man verzichten in dem man jede Seite ne feste id gibt (zb eine fortlaufende nummerrierung). dabei müsste man die wiki-namen im "wiki-quelltext" für die datenbank so durch die id ersätzen und beim betrachten des quelltextes dies wieder rückgänig machen.

der vorteil von BerndSchiffer is mir dann auch klar, man ändert nur den titel welcher sich hinter der id verbirgt und schon hatt man auch alle links auf jeder betroffenen seite verändert. soweit so gut, aber das suchen nach den backlinks wird dann wesentlich aufwändiger. man muss dann ja die ganzen wiki-quelltexte nach der id durchsuchen, da man woanders ja nicht die informationen (zwegs vermeitung doppelter datenführung) stehen hat. wenn man also nach ner umbenennung schaun will welchen "schaden" man angerichtet hat (auf welchen seiten sich die umbenennung bemerkbar machte) darf man die datenbank richtig schuften lassen. ne danke, da weich ich doch lieber von den paradikmen der datenbankführung ab.

naja, zum glück brauch ich der gleichen in meinem konzept nicht. :D

BerndSchiffer: Nee, Sebastian, dieser Zusammenfassung stimme ich nicht zu. Wo und womit hab ich denn den Eindruck erweckt, ich würde ein ID-Konzept verfolgen? Die Aussage von sigi, womit diese Diskussion startete, war soll die seite umbenannt werden, so wird einfach nur der name im namens- oder seiten-knoten ausgetauscht . "und gut is"; ich wollte lediglich zeigen, daß dies nicht so einfach geht, oder erfahren, warum es denn so einfach gehen könnte.

Ich für meinen Teil favorisiere Deine von Dir zusammengefasste Meinung von sigi, glaube aber nicht, dass er das so sieht, da solch eine Tabelle, wie Du richtig feststellst, eine doppelte Datenhaltung wäre; aus meiner Sicht ist doppelte Datenhaltung bzgl. einer persistenten, d.h. auf einem permanenten Datenspeicher (wie z.B. Festplatte), und einem im Speicher gehaltenen Datenbestand völlig in Ordnung - es kann vieles sehr vereinfachen. Aber sigi meint, nur den Knoten umbenennen zu müssen, den er ursprünglich umbenennen wollte, nicht aber die Referenzen auf diesen Knoten; bei doppelter Datenhaltung müsste er noch mehr umbenennen...

sigi: ich hätte große lust, mal das ganze grundlegend zu klären . die richtige (kern)mannschaft scheint mir schon beisammen zu sein . leider geht das hier nicht, einfach, weil das wiki-konzept hier nicht dialektisch organisch angelegt ist (was bedeuten würde, dass sich leute ihre themen suchen und diese sich wiederum in wechsel·wirkung zu den leuten frei entfalten) und das schubladen·konzept (zu sagen: wir machen jetzt ein fach·wiki) ist mir einfach zu grausam (der letzte große experte darin, menschen in schubladen zu stecken, war hierzulande übrigens hitler) .

BerndSchiffer: Weitere Gründe für das SeitenUmbenennen sind Rechtschreibfehler (im DseWiki gab es mal eine Seite ObjektOrientierteProgrammierung, an der bemängelt wurde, dass es objektorientiert heißt, also in einem Wort, und nicht Objekt orientiert, also zwei Wörter; diese Seite wurde nach ObjektorientierteProgrammierung umbenannt) und auch Fälle, in denen eine andere Bezeichnung als den Inhalt treffender angesehen wird (im DseWiki gab es mal statt den hier vorherrschenden Ordnern die Kategorien [oder war das doch schon hier im Gründerwiki gewesen?], die dann später in Ordner umbenannt wurden). In beiden Fällen existierte vor der Umbenennung keine semantische Identität von Name und Inhalt. Meine Vermutung: semantische Identität ist an den Kontext gebunden, der zeitabhängig ist, d.h. semantische Identität kann veralten da außerhalb asynchron mit dem Kontext. Wo sich vor Wochen noch alle einig waren, kann heute durch Umgebungsveränderungen viel Diskrepanz entstehen.

Die Seltenheit von Umbenennungen ist ein Henne-Ei-Problem: sind Umbenennungen so selten, weil sie so schwer durchführbar sind oder weil so selten Situationen vorherrschen, in denen eine Umbenennung adäquat wäre? Analog die Programmierung: vor dem aufkommen von DseWiki:RefactoringBrowserwar war es sehr mühsam, (fehlerfrei) Variablen, Klassen, Methoden und andere Bestandteile der Programmierererzeugnisse umzubenennen. Als dann automatisierte Refactorings Einzug hielten, war nur noch ein Knopfdruck nötig. Es vergeht bei uns (mir und Programmierpartnern) keine Stunde des Programmierens, in der wir nicht dutzende Umbenennungen vornehmen würden. Besonders, wenn wir an altem Code erneut hand anlegen, an dem seit Monaten nicht mehr programmiert wurde, d.h. der Kontext sich geändert hat, ändern wir Bezeichner, die eben nicht mehr das widerspiegeln, was vor Monaten noch volle Gültigkeit hatte. SeitenUmbenennen ist eine Art, Änderungen zu begegnen, die wir ansonsten vielleicht ignoriert würden; Dynamik, wo Statik vorherrschen würde. Ist es nicht wikiisch, dynamisch zu sein?

Bernd, ich weiß nicht Recht, was ich dazu sagen soll. Gute Namen zu haben ist immer ein Vorteil, im Wiki wie in der Programmierung. Je höher der Aufwand der Umbenennung ist, umso eher macht man sich um die Namen Gedanken. Wenn es leicht ist, sagt jeder: Der Name hat keine Bedeutung, kann eh jeder ändern. Im Konkreten bedeutet eine Änderung der Handhabung von Seiten und ihren Namen eine Änderung von Implementierungsdetails. Das ist nicht durch eine Diskussion zu ändern. Jemand kann einen Implementierungsvorschlag machen (den sehe ich hier noch nicht). SWikiWiki hatte sowas: Die Seiten waren nummeriert und irgendwo gab es eine Zuordnung Nummer <-> Name. Das löst Probleme und wirft andere Probleme auf. Jemand kann Lust haben, so etwas zu implementieren (aber versteht bitte, dass ich mich dazu nicht verpflichtet fühle) dann unterstütze ich das bzw. freue mich, aus den Erfahrungen lernen zu können. -- HelmutLeitner

BerndSchiffer: Schöne Zwei-Dinge-Diskussion

Terminologie angleichen klingt gut und bin ich eigentlich immer für. Ja, Du hast das anfassen richtig interpretiert. Anfassen bedeutet, Dinge zu ändern. Wenn ich eine Änderung in einem Programm durchführe, schaue ich zuerst, wieviele und welche Klassen ich ändern (also anfassen) muss. Je weniger Klassen ich anfassen muss, desto besser.

Wenn ich Dich nun richtig verstanden habe, dann ist A der Knoten, A' der Name des Knotens A und A" der Inhalt des Knotens A. Wenn Du schreibst, A ... ist teil-knoten von B, C und D, dann meinst Du doch, dass B, C und D auf A zeigen (also eine Referenz, einen Link, auf A haben), richtig?

Wenn dem so ist, so wird diese Referenz, dieser Link, auf A in B, C und D gespeichert. Und diese Referenz wird in einem Wiki über den Namen einer Seite, also eines Links, repräsentiert. Somit musst Du, wenn Du A' (und damit auch A) änderst, auch B, C und D ändern (genauer B", C" und D"). Ergo musst Du nicht nur A anfassen...

Anders ausgedrückt: wenn Du in B (der Inhalt von B) stehen hast "siehe A'", und A' wäre eine Referenz direkt auf A, so dass bei einem Klick auf "siehe A'" der Klickende auf A kommen würde, dann gilt bei Umbenennung von A', dass weiterhin in B stehen würde "siehe A'", aber bei einem Klick darauf der Klickende nicht auf A, sondern auf die Umbenennung (gleich irgendein anderer Knoten) gelangen würde. Das'' wäre absolut nicht okay.

Puh, theoretische Materie das!

BerndSchiffer: Das sind zwei mögliche Szenarien, in denen SeitenUmbenennen nötig wären, wobei Spezialisieren als auch Themaabweichung eine bestimmte Sorte darstellt. In beiden Fällen möchte man nicht alle, sondern vielleicht nur eine Teilmenge aller referenzierenden Seiten anpassen. Dies würde vielleicht über einen Dialog zwischen WikiEngine und Benutzer möglich sein, über welchen der Benutzer wählen kann, in welchen der referenzierenden Seiten er die betreffenden Links ändern möchte und in welchen nicht. In den Seiten, in denen er die Links unangetastet belassen möchte, entstehen nach dem SeitenUmbenennen VerlangteSeiten?. Diese können dann mit adäquatem Inhalt gefüllt werden.

SK-Genius: ja, mit ner auswahl währe das schon ne sauberere angelegenheit über die ich mir auch mal gedanken gemacht habe. habs aber wieder verworfen weil es mehr vom benutzer verlangt. mein wiki soll halt gross und für jedermann sein. ich will da niemanden die wahl zumuten bei hundert bäcklinks ne wahl zu treffen welches nun umbenannt werden sollte und welches nicht. bei kleinen wikis wie diesem ist das aber durchaus denkbar (denk ich mal).

SK-Genius (Sebastian Kühn): keine ahnung wie du die zusammenhänge entschlüsseln willst. oder anders gesagt, wie du herausfinden willst, welchen link du ändern darfst und welchen nicht. ich bin immer noch der meinung, ne seite bzw "ein knoten" dazwischen zu schieben wäre das einfachste.

sigi: beispiel: du hast ne seite "benziner" mit 10 unter(unter)seiten (kreis-verlinkungen ausgeschlossen oder gekennzeichnet) und nur für die möchtest du motor in verbrennungsmotor ändern, oder du hast ne seite "meine liebling-stars" mit 20 unter(unter)seiten und möchtest nur dort michal jackson in janet jackson umändern . das würde aber heißen, du hast nicht den namen einer seite geändert (wie in den obigen beispielen, wo du praktisch die seite selber änderst), sondern eine zusätzliche geschaffen und änderst nur in einem bestimmten bereich bestimmte links . willst du mehrere bereiche umlinken, so geht auch das . du kann sogar ein muster für diese bereiche angeben, einen sogenannten match-baum .

sigi: bernd, keine doppelte daten-haltung, sondern eine doppel-verkettung . nichts, was einen programmierer (geschweige denn einen computer) ins schwitzen bringen sollte . für manche probleme das mittel der wahl (z.b. alle back links im wiki (das mit der volltext-suche meinst du doch nicht wirklich ernst (oder kam das von helmut)?)), für (viele) andere nicht .

SK-Genius: stimmt, bei unterseiten macht das sinn. daran hat ich nicht gedacht weil ich für meine WikiEngine keine verzeichnisstruktur geplant hab. is halt ne menschlich schwäche von mir, dass ich alles nur auf wikipedia und mein TuToRi beziehe. ^__^

sigi: ja, so geht es wohl uns allen . deshalb fordere ich ja auch immer eine übergreifende gemeinsame sprache . vielleicht ergibt sich ja hier sowas wie ein ansatz . (übrigens heißt es stornieren und nicht stonieren ( http://tutori.de))

jeder artikel kann unter mehreren namen gleichzeitig erreicht werden. diese namen sind in einer eigenen tabelle den artikel zugewiesen, welche über ne id verwaltet werden. dies ermöglicht, dass man titel nach belieben dem artikel hinzufügen oder auch entfernen kann. dies führt hoffentlich zu einer lockereren einstellung zum umbenennen bzw allgemein zur namensgebung, da dabei ja die alten links nicht ins leere führen, wenn man nen titel hinzu fügt.

sigi: camelcase war echt ne schnaps·idee . ich finde, die einfachste art, einen link zu erzeugen, ist, ein ausrufe·zeichen vor irgendeine zeichen·kombination zu setzen . will man nach einem ausrufe·zeichen keinen link, so lässt man einzeichen frei .
aber letztendlich meine ich, und jetzt sind wir wirklich beim thema, dass im wiki der zukunft jedes wort ein link ist (ausser speziellen verknüpfungs·symbolen) . ich würde das dann aber nicht id nennen, sondern jedes wort erhält einen index . d. h. zu jedem wort gehört ein (durchnummerierter)verwaltungs·knoten, der auf das wort zeigt (jedes wort ist nur einmal im speicher) und auf eine (einfach verkettete) liste, die alle zusammenhänge (auch wieder knoten) auflistet, in denen das wort vorkommt . d.h. auch worte kommen im text nur als referenzen (wort·knoten-index) vor.

SK-Genius: das camelcase kommt so viel ich weiss aus der informatik wo man für bezeicher keine freizeichen benutzen darf, weil dies als bestimmtes trennzeichen reserviert ist. dort gibt es als aushilfe nur den unterstrich und das camelcase. wenn man sich wikipedia anschaut, kennt es ja eigentlich auch keine freizeichen in den artikelnamen. im eigentlichen werden unterstiche nur als diese ausgegeben (siehe url). ein lehrzeichen in der url sieht ja auch als "%20" codierung wirklich beschissen aus. das camelcase war also meiner meinung nach nur ein versuch, das leerzeichen zu umgehen. naja es wäre ein wunder, wenn der erfinder bei nicht einer entscheidung daneben gegriffen hätte. besonders da er ja nicht auf vorangegangene ähnliche projekte zurückgreifen konnte.

jedes wort zum link zu ernennen, ist bestimmt nicht der nächste schritt in der welt der wikis. damit hätte man ja nur ein reines wörterbuch erschaffen, welches sich selbst versucht zu erklären. nein, es muss möglich sein, wortgruppen als link auszuwählen. ob es eine automatisierung geben wird, welche die beste wortgruppe zum link erklärt, halt ich da eher für möglich (wenn auch nicht für sehr wahrscheinlich). ich denk, dass es eher in die richtung gehen wird, dass man eine textstelle markiert, ne taste drückt und entweder auf dem entsprechenden artikel landet, oder wenn es den nicht geben sollte, so landet man damit in ner suchmaschine, welche die zu dem makierten am besten passenden links anzeigt. zumindest hab ich es so für mein wikibrowser geplant, der in so 10 jahren rauskommen soll (sory, aber ich bin nur hobbyprogrammierer ohne team, da gehts nicht schneller ).

sigi: wir können uns ja zusammentun, dann geht's schneller .
zwei dinge: du schreibst weiter oben: jeder artikel kann unter mehreren namen gleichzeitig erreicht werden. ich kenne das problem eigentlich nur anders rum: verschiedene seiten, aber mit gleichem namen . was machst du in dem fall?
du schreibst weiter: es muss möglich sein, wortgruppen als link auszuwählen. das ist genau der nächste schritt . wir brauchen einen browser, der text in seine haupt·gruppen zerlegt, wie hier zum beispiel die absätze oder die beiträge einzelner leute . diese können dann eingeklappt angezeigt werden (z.b. das erste wort, falls ein doppel·punkt folgt, sonst die ersten beiden wörter, oder fals eine überschrift da ist, dann diese) und zum lesen oder ed(it)ieren einzeln oder insgesamt ausgeklappt werden .

SK-Genius: es können natürlich nur titel vergeben werden die noch nicht benutzt sind, wodurch ne doppelte vergebung nicht möglich ist. da die titel wie bei wikipedia aus "belibig" vielen wörtern bestehen kann, dürfte eine namensfindung nicht all zu schwierig sein. sollte es es zwei artikel geben, welche gerne über den selben titel aufgerufen werden möchten (zb bei abkürzungen mit 2 bedeutungen), so muss halt ein artikel zwichengeschaltet werden, welcher auf die zwei interpretationen hinweist und dorthin linkt (ganz wie in wikipedia).

ps: hilfe kann ich gebrauchen, kannst du programmieren?

sigi: wie gesagt: hobby-programmierer älteren kalibers . 68000-er maschinen·sprache(äh, nicht mehr so ganz aktuell, aber vermittelt gute grundlagen und ich war einer der gründlichsten) . c und c++ . wobei ich c++ allerdings gern durch baumL ersetzen würde (eine sprache, die bisher nur ganz wenige kennen und die noch voll in der entwicklung ist (in 10 jahren vielleicht (d.h. ich kann hilfe gebrauchen ))) .