Collecting and Categorizing Web Links in Org-mode

These are my frequently used links, marked with :noexport:, so they don’t appear in the public link list. They are placed at the top of the file for quick access.

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

These links are visible on the blog. My site generator processes this section and turns it into a dynamic list using a bit of CSS magic.

This is where things get interesting. Right now (March 4, 2025), this section holds around 450 links, categorized with up to four tags. The organization, however, is… let’s say, questionable. More of a dumpster fire, really.

Basically, the same chaotic mess as the private links. just without any tags assigned yet.

So, my tool’s job is to process sections 3 and 4.

Of course, otherwise, it would be too easy. Tags are inherently non-hierarchical. If I tag a link with a and b

* Link :a:b:

I can create two different trees:

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

As soon as I have three tags, I can insert the additional tag at three different levels. in each of the two trees. resulting in six possible trees.

The mathematical representation is 3! (i.e., 3 factorial). If anyone remembers exponential growth from the COVID era, that’s nothing compared to factorial growth. it’s child’s play in comparison.

With six tags, we’re already at 720 possible trees, and just eight tags result in 40,320 trees.

The common approach would be to use them all. That means a link with four tags would appear 24 times in the link list. but there would also be 24 ways to find it. Roughly estimated, my 450 links would result in about 3,000 links in the output file. And that’s too much for me.

Many of these paths wouldn’t even make sense. Suppose I bookmark the location where I last parked my car:

* Auto :germany:munic:mainstreet:

Then I don’t think, "Hmm, I remember parking on Main Street, so show me all the countries that have cities with a Main Street so I can pick the right one."

So, I need to cut down the trees that don’t make sense. This brings in the second key word: the structure should be a logical tree. But, as should have been clear even before Trump, there are some pretty strange interpretations of logic. and that’s not even considering alternative logic.

Computers aren’t particularly good at determining what makes sense in a search. So instead, I rely on a different criterion: frequency. Because counting is something computers are really good at.

If my file contains the tag emacs 200 times but the tag orgmode only 100 times, then the tree looks like this:

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

That works pretty well, but now and then, some strange hierarchies still appear. especially with tags that are rarely used overall. In those cases, a single extra use can already make a difference in how the sorting plays out.

In most cases, rare tags don’t really matter. But when this happens with major (frequent) tags, it can be quite annoying. That’s why I cheat a bit. Sticking with the car example, I’d actually write it like this:

* Auto :Germany:Munic:mainstreet:

See the difference? The first two tags are now capitalized. For my tool, this signals that country and city are hierarchically more important than the street. This still leaves two possible trees, but it eliminates four others right away. I can only enforce one strict hierarchy level this way, but it helps handle the edge cases quite well.

Why is this cheating? Well, according to the textbook, tags don’t carry hierarchical information, and my programmer’s heart does feel a little dirty about it.

Now, on to the technical part, in case anyone wants to implement this in another language:

Anyone interested in voting systems will have realized that there are dozens, if not hundreds, of different voting methods, each leading to slightly different results and optimized for various goals (fixed number of seats, weighting by stock share, minimizing the tags traveled by horse to the capital, etc.).

This also applies to the voting in this algorithm. Currently, every link votes for every tag that benefits it in some way with one vote. However, other variants could also be considered:

• If a link sees 3 possible trees for Tag A and 2 possible trees for Tag B, it could vote with 3 and 2 votes for the respective tags.
• The votes could be weighted based on whether a tag is immediately needed at this level or possibly further down the tree.
• etc.

Overall, I am already very satisfied with the results. My repository with the current state of the tool can be found (here).