konnexus

Gratz! Und so schön sieht es aus. Da bin ich ja prompt neidisch. Meinen Namen darfst Du überigens ausschreiben, wenn du magst.

Danke!

@ben_: sehr gut! und schon geschehen. konnexus.net/ben ist dein topic :-)

Habe ich schonmal erwähnt, dass ich deine Gestaltung/Visualisierung hier einfach wundervoll finde, gerade auf den Topic Maps-Seiten? Nicht? Dann eben jetzt und hiermit.

Und ja, ich könnte ebenso wie ben_ gerade neidisch werden.

@fym: ich hab ja einen traum. der traum ist, dass @ben_ und du - dass ihr auch eure topic maps aufbaut. und dann ich hier nicht nur ausgeben werde, was ich zu verwandten themen geschrieben habe, sondern auch ihr. ein netz der freunde, sozusagen.

@fym: übrigens hast du natürlich auch dein eigenes topic bei mir:
konnexus.net/fym

Ach Mensch Jungs … ihr bringt mich ja echt in Bedrängnis. Na gut. Morgen geht's los. Morgen mach ich wieder was am Semantic Weblog.

Bis dahin aber: Sag mal Konnexus … war nicht ein Grund dafür, dass Du auf Nodes als Topics plädiert hast die Tatsache, dass Nodes im Unterschied zu Terms auch kommentiert werden können? Hast Du das abgeschaltet, oder darf ich nur zu Fyms Topic speziell keine Kommentare schreiben?

Das ralle ich ja jetzt erst. Verlinkt sind ja gar nicht die Topics sondern die Terms.
http://konnexus.net/ben
Ist "in echt" diese URL
http://konnexus.net/taxonomy/term/163
und nicht jene:
http://konnexus.net/node/238

Da stellt sich mir die Frage: Müssen Nodes wirklich Topics sein, oder kommen wir auch mit Terms zurecht? (Die Frage geht auch auch Fym!)
Nodes haben den Vorteil grundsätzlich flexibler und mächtiger zu sein. Kommentierbarkeit ist da nur ein Beispiel.

Mit Terms haben wir den Vorteil, dass wir inzwischen ja auch ein Term-Description Feld haben uuuund … und das ist mir eigentlich noch wichtiger: Wir haben keine Doppelte Datenhaltung. Legt man ein Tag-Term an, ist auch das Topic da. Löscht man es, ist auch das Topic weg und Benamst man es um … ihr versteht, was ich meine.

Nebenbei: Ich hab Dich ja gewarnt, dass das keine kluge Idee ist, URLs ohne ein weiteres Slash direkt an die Domain zu flanschen: http://konnexus.net/drupal/ zeigt auf die Startseite, warum auch immer …

@ben_:
ich hab die terms verlinkt, weil ich mir nicht besser zu helfen wusste, unter einem begriff alle dazugehörigen nodes anzuzeigen. bei terms war das einfach. und die daten aus dem entsprechenden topic zu holen auch, dank deiner funktionen im modul.

ob man terms statt topics verwendet: generell denke ich, man sollte es zusammenlegen. oder denkt ihr, dass man topics wirklich häufig kommentieren wird? für mich waren topic-definitionen immer eher ein suggerat aus dem, was ich eh in den artikeln behandle. und in den artikeln (nodes) kann man das dann diskutieren. vielleicht liege ich aber auch falsch.
und für konnexus.net - da hab ich ja ganz spezielle anforderungen. meine terms kommen zum großen teil als tags aus delicious. den rest der geschichte werdet ihr schon kennen: die tags sind a) auf englisch, und b) nur aus ziffern und buchstaben bestehend, ohne lehrzeichen oder ähnliches. deswegen ist für mich die hochzeit von topics und terms ganz praktisch: die terms lasse ich so wie sie sind. sie bilden auch die grundlage für die urls: konnexus.net/. und in die topics schreibe ich dann den begriff, den ich überall in der darstellung haben will. beispiel: "semantic weblog", nicht "semanticweblog". wenn ich entwickler wäre, dann würde ich das anders aufsetzen: ich würde beim import aus delicious ein neues term anlegen, würde dann im url-alias den delicious-tag hinterlegen, und den term-namen beliebig ändern. bei jedem weiteren import aus delicious würde ich die delicious-terms gegen die url-aliase der konnexus.net-terms prüfen. wenn eine übereinstimmung ist, werden die tags eben diesen terms zugeordnet.

thema "URLs ohne ein weiteres Slash direkt an die Domain zu flanschen":
ich bin sehr zufrieden. "drupal" hat wohl das gleiche schicksal erwischt wie z.zt. "nexum" - bei "drupal" liegt das ganze drupal cms unter diesem unterverzeichnis. bei "nexum" ist es ebenfalls ein unterverzeichnis. den "nexum"-ordner kann ich verschieben, "drupal" dagegen nicht. ich schätze "drupal" hat einfach pech gehabt. oder ich benenne den term einfach um.

jedenfalls: diese fälle sind äußerst selten. dagegen nutze ich total häufig konnexus.net/, um meine links oder artikel nachzugucken. daher ist das super praktisch für mich.

Hm. Achja. Verflucht, die unterschiedliche Schreibung beim Import. Das hatte ich vergessen. Das ist latürnich ein Argument.

Krass … das heißt ja, dass Du beim Rendern die Tags in ihre Topic-Schreibung umwandeltst … Mensch, Konstantin … das ist echt krass.

Ich bin inzwischen eigentlich soweit, das Semantic Weblog Modul nochmal from Scratch neu zu schreiben. Mit Terms als Topics und den Rest so gut es geht über CCK. Sobald Drupal 7 da ist könnte man dann Deine Daten sauber migrieren, weil man da ja auch Terms mit CCK-Felder ergänzen kann … guter Plan?

@Fym, was sagst Du dazu?

By the way: Es wäre Super wenn Du Anker der Gestalt "comment-3050" an die Kommentare basteln könntest, dann könnte man die verlinken …

@ben_: krass, dass du das modul komplett um-modelst. heißt das, dass meine ganzen semantischen verknüpfungen dann auch flöten gehen? samt topic-definitionen?

kommentare ankern - mach ich gern. komme in den nächsten 2 tagen nur nicht dazu ...

Ich weiß nicht, warum man hier auf meinen Senf wartet- Lehrer warten auf Schüler? Ich fühle mich komisch.

Nagut, dann. Auf der Pro-Node-Seite: Es sind verdammte Nodes. Mit denen kann man so schöne Sachen anstellen, menno.

Das war's aber schon auf der Pro-Seite von mir ;)

Contra-Node-Topics:

Denn ich muss gestehen, dass ich den Sinn vom Topic-Submodul damals (wie wahrscheinlich heute noch größtenteils) nicht verstanden habe bzw. nachvollziehen kann. Wie es ben_ schon schrieb: Wenn die Terms selbst zugleich Topic sind bzw. sein können, ist das zumindest in jener Hinsicht flexibler (erstellen, löschen, ändern ect.). Nicht anders kannte ich es ja von Wordpress her bzw. der entsprechenden Variante des SW-Plugins. Was mir aber ebenso an den Node-Topics übel aufstößt, hat ben_ auch schon erwähnt. Die Datenredundanz. Für meinen Gebrauch ist es einfach unsinnig und unnötig, im Prinzip ein weiteres Mal ein Topic im System zu haben, wenn ich es mit dem Term selbst schon habe.

Ich würde die Abkehr von Topic-Nodes also grundsätzlich unterstützen, wüsste aber zu gerne, wie man dann die Verknüpfungen/Assoziationen realisieren kann (und sollte?). Vor allem in Hinblick auf die Bedienfreundlichkeit. Wenn ich stets nach einem node/add in /admin gehen und mir die entsprechenden Begriffe zwecks der Eingabe einer Term-Description dort heraussuchen müsste, dann würde das meinen Enthusiasmus der Nutzung wohl merklich abträglich sein. Zumal die ganzen Listings (terms, nodes, comments ect.) unter /admin in Drupal in meinen Augen nicht so ideal realisiert sind.

Ok, das soll es dazu erstmal sein. Bestimmt ein paar Dinge vergessen, die ich eigentlich noch hätte schreiben können, aber so ist das halt.

@konnexus: Den Traum der vernetzten Topic-Maps kann ich gut verstehen. Als Aufsatz auf das SW-Modul könnte man das dann vielleicht später mal anpacken?

@konnexus²: ... deine Topic-Handhabe. Junge, wie ben_ es schon geschrieben hat- krass. Krass, aber ziemlich gewitzt. Mich regt die Handhabe von Tags bei den Bookmark-Diensten ja regelmäßig auf. delicious ist wegen der Leerzeichen-Phobie von mir verpöhnt (ich habe das immer versucht zu umschiffen, indem ich nach dem Import des Bookmarks die Terms manuell bei mir geändert habe, aber das war auf Dauer einfach zu...) und was die "Tags" beim GReader sollen, kann ich bis heute nicht nachvollziehen (zumal die, wenn ich mich letztens nicht verguckt habe, überhaupt gar nicht im Feed der shared items auftauchen, verdammtnochmal).

@Konnexus: Nein, Deine semantischen Relationen gehen ggf. latürnich nicht flöten. Die migrieren wir fein. :)

@Naja: Du bist 1/3 der Zielgruppe aktiver Nutzer, da hat Deine Meinung schon gewicht.

Für die Verknüpfung habe ich zwei Ideen. Alle beide gehen in die Richtung, wie die Options-Felder in Wordpress liefen. Da muss ich ggf. Nicos superior Jquery Skills anzapfen aber das wird schon.
1. Im Node-Creation-Form ein weiteres Fieldset bestehend aus einem Input Feld (Term 1), einem Drop-Down-Feld (Assoziation) und einem Input-Feld (Term 2). Speicher geht denn über einen JS-Button.

2. Oder das gleiche als Block, den man über, unter oder neben die Node-Creation-Form setzen kann. Oder sonst wo hin.

Dazu ergänzend werden alle verknüpften Terms natürlich AN dem dazugehörigen Term angezeigt und können von dort aus gelöscht oder bearbeitet werden.

Guter Plan? Ich fass das nochmal in der Wave zusammen. Später auch in einem Blogeintrag.

die diskussion geht bei ben_ weiter.