Sammeln und kategorisieren von Weblinks in Orgmode

Wie man sieht sind diese Links mit :noexport: getaggt, und tauchen daher nicht in der öffentlichen Linkliste auf. Es sind Links. die ich selbst häüfig aufrufe. Deher stehen sie in der Datei ganz oben. und sind bereits sichtbar, wenn ich die Datei öffne

* ------ Quick Links ----- :noexport:
 :PROPERTIES:
 :VISIBILITY: children
 :END:

Dies sind alle Links, die im Blog sichtbar sind. Aus den Hierarchie-Ebenen generiert mein Layout mit ein wenig CSS-Magie dann eine dynamische Liste. Mein Python Tool lässt alles bis zum Ende dieses Abschnitts in Ruhe.

Hier wird es nun interessant. Heute (2025-03-04) befinden sich hier etwa 450 Links. Diese Links sind mit bis zu vier Tags versehen, und wurden bisher einigermassen sortiert und kategoriesiert gehalten. Wobei man schon an das "einigermassen" nur niedrige Massstäbe anlegen darf. Ach wen lüg ich da an - es war ein Dumpster-Fire.

Im Prinzip das gleiche Durcheinander, wie bei den privaten Links, nur, dass ich hier noch nicht einmal Tags vergeben habe.

Es sind also die Abschnitte 3 und 4 um die sich mein Tool kümmern soll,

Natürlich alles andere wära ja auch zu einfach. Tags sind ihrer Natur entsprechend alle gleichwertig. Sie enthalten keine Information über eine Hierarchie. Mal angenommen ich habe den folgenden Link mit den Tags a and b:

* Link :a:b:

Dann kann ich daraus schon 2 mögliche Bäume bauen

├── a
│   └── b
│       └── Link
└── b
    └── a
        └── Link

Sobald ich 3 Tags habe. kann ich das zusätzlich Tag in 3 möglichen Ebenen einfügen - in jeden der beiden Bäume - und erhalte damit schon 6 mögliche Bäume. die mathemathische Darstellung wäre 3! (sprich: 3 zur Fakultät) Falls jemand noch exponentielles Wachstum aus der Covid Zeit kennt. Das ist gegen fakutatives Wachstum auf Kindergarten Nivau. Nehmen wir 6 Tags sind wir bereits bei 720 möglichen Bäumen und nur 8 Tags reichen für 40320 Bäume.

Der gängige Ansatz wäre, sie alle zu nutzen, Dann taucht ein Link mit 4 Tags eben 24 Mal in der Linkliste auf, aber es gibt eben auch 24 Wege ihn zu finden. Grob Überschlagen würde das bei meinen 450 Links etwa 3000 Links in der Ausgabedatei ergeben. Und das ist mir zu viel. Eine Menge der Pfade ergeben dabei nicht wirklich einen Sinn. Mal angenommen ich verlinke den Ort, an dem ich mein Auto zuletzt geparkt habe:

* Auto :germany:munic:mainstreet:

Dann denke ich ja nicht "Hmm ich weiss noch, das ich in der Mainstreet geparkt habe, also zeig mir mal alle Länder in denen es Städte mit einer Mainstreet gibt. damit ich mir daraus die passende aussuchen kann"

Also muss ich diejengen Bäume abholzen die keinen Sinn ergeben. Hier kommt das zweite entscheidende Wort hinzu. Es soll eine logische Baumstruktur werden. Aber nicht erst seit Trump sollte klar sein. das es die seltsamsten Varianten von Logik gibt. und da ist alternative Logik noch nicht mal berücksichtigt. Und bei der Suche noch etwas sinnvollen sind Computer nicht wirklich gut. Also behelfe ich mir mit einem anderen Kriterium, der Häufigkeit. Zählen können Computer nämlich recht gut.

Wenn ich in meiner Datei 200 mal das Tag emacs habe aber nur 100 mal das Tag orgmode, Dann sieht der Baum so aus

└── emacs
    └── orgmode
        └── Link

Das klappt dann schon ganz gut, Aber hin und wieder gibt es noch ein paar seltsame Hierarchien, besonders wenn es sich um Tags handelt die insgesamt selten genutzt werden. da kommt es dan auf eine Nutzung mehr oder weniger schon an, wenn es um die Sortierung geht

In den meisten Fällen kommt es bei den seltenen Tags sowieso nicht darauf an. Aber wenn mir das mit großen (häufigen) Tags passiert ist dass schon ärgerlich. Und deshalb mogle ich ein wenig. Um mal be dem Auto Beispiel zu bleiben - das würde ich in Wirklichkeit so schreiben:

* Auto :Germany:Munic:mainstreet:

Siehst du den Unterschied? Die ersten beiden Tags sind nun gross geschrieben. Für mein Tool ist das der Hinweis, dass Land und Ort hierarchisch wichtiger sind als die Straße. Es gibt damit immer noch 2 mögliche Bäume, aber 4 Bäume sind damit sicher verhindert. Ich kann damit nur ein zwingende Hierarchiestufe bestimmen, aber damit die Zweifelsfälle, die Auftreten könnten, ganz brauchbar abfangen.

Warum ist das gemogelt? Nun Tags tragen laut Lehrbuch nun mal keine hierarchische Information, und mein Pogrammiererherz fühlt sich auch ein wenig schmutzig an. Nun aber zum technischen Teil, falls das jemand in einer anderen Sprache nachbauen möchte:

Wer sich für Wahlrecht interresiert wird festgesteiit haben, dass es dutzende, wenn nicht hunderte verschiedene Wahlverfahren gibt. die alle zu leicht unterschiedlichen Ergebnissen führen,und auf verschiedene Ziele (feste Sitzanzahl, Gewichtung nach Aktienanteil, Minimierung der zu reitenden Tage bis zur Hauptstadt) optimiert sind.

Das gilt auch für das Voting in diesem Algorithmus. Aktuell voted bei mir jeder Link für jeden Tag der ihm irgendwie nutzt mit einer Stimme. Ebenso wären aber auch andere Varianten denkbar:

• Wenn ein Link 3 mögliche Bäume für Tag A sieht und 2 mögliche für Tag B, könnte er mit 3 bzw. 2 Stimmen für die jeweiligen Tags stimmen.
• Die Votes könnten danach gewichtet werden ob ein Tag unmittelbar in dieser Ebene nötig ist, oder möglicherweise erst tiefer im Baum.
• etc.

Alles in allem bin ich mit dem Ergebniss aber schon sehr zufrieden. Mein Repo mit dem aktuellen Stand des Tools befindet sich hier