brainbaking/content/post/2024/06/visualizing-blog-post-links...

6.6 KiB

title date tags categories
Visualizing Blog Post Links With Obsidian 2024-06-10T13:40:00+02:00
obsidian
backlinks
hugo
software

Brain Baking has been powered by the static site generator Hugo for a good decade now. Everything I've written and published here has come to fruition with the help of Sublime Text and Hugo. Yet in 2021 I started using another Markdown-powered editor called Obsidian to edit my digital notes before they make it to this blog. The inevitable question then becomes: why not write articles directly into your Obsidian Vault and publish from there?

There are ample articles from others exploring that thought but they all start in reverse: they build a Vault with notes in Obsidian and want to see it published with Hugo. Brain Baking already contains 427 articles and I am not looking forward to converting these to an Obsidian-compatible syntax, only to be using another tool to convert it back to HMTL. But wait, why wouldn't Hugo files living in /content be compatible?

Because of one big stinker: links. Default Markdown-style links I use to link this article with others in the form of [blah](/post/yyyy/mm/other-article/) include a lot of problematic substrings for Obsidian:

  • The leading slash /post points to the hosted website root. This isn't compatible with sub-vault inclusion systems in Obsidian, so root slashes aren't supported.
  • The path itself starts at post but lives in content in the root of my Brain Baking repository. At what level then are you creating an Obsidian Vault?
  • The trailing slash other-article/ confuses Obsidian into thinking it's a different file. The graph view points to a non-existing file.

Even though you were to disable [[wikilinks]] in Obsidian, you'll have to apply a bunch of fancy regexes before Obsidian is able to process and link the documents correctly. I came up with a quick and dirty regex \[(.*)\]\(/post/[0-9]+/[0-9]+/(.+)/\) to replace Markdown-links with [[$2]], getting rid of the path entirely. I've seen others like this hugo-wikilinks repository and Quinn Casey relying on the same dumb trick. Of course, that breaks the Hugo rendering pipeline, resulting in <a/> HTML tags that point to nowhere.

An even bigger problem I won't go into is the way I organize my static files: images are included using ![](../image.jpg "description") because I do not want to create a directory for each post: they live in /static/post/yyyy/mm---but get copied over by Hugo, so the static folder doesn't really exist. Confused yet?

In sum, it is not possible to simply import a Hugo content or post directory into an Obsidian Vault and call it a day. The most compelling reason to write directly in Obsidian isn't the better Markdown support but (1) the graph view with (implicit) backlink support and (2) the fuzzy search and auto-include while typing [[ to link to an existing article. I guess I'll have to try and find similar plug-ins for Sublime Text for that. Another option would be to write a tool that converts from A to B so that Hugo can convert to C. but that sounds like an unhealthy case of over-engineering to me.

Still, using the above dirty regex, I was able to extract a partial graph view of connected blog posts:

This does not include tags or categories which should appear as heavily linked nodes in the graph. In Obsidian, concepts and tables of contents are usually Markdown files as well, making these links explicit.

I found the above graph very interesting, especially its spider-like form thanks to my more recent habit of writing monthly overview posts that are form a heavily linked web. The edge links pointing up and down are mostly these kinds of posts.

What stood out the most, however, was that almost all posts are written within context: they're always linked to at least one other relevant post. I love providing the reader (and thus, mostly myself) options to discover similar articles, hence the You Might Also Like... footer beyond every post, listing five related posts using tag intersections and true backlinks.

Even though that messy graph is meaningless on its own, I wondered if introducing an explicit layer would be a good idea to easier find stuff. In Hugo terms, that means adding another taxonomy next to the global category and micro tag levels. What if I could separate indexes in /archives into clusters called series---clusters I would identify using Obsidian's graph?

After a few evenings of messing around, I came up with a couple of series belonging to a specific category:

webdesign
  - blogging about blogging
  - hugo static site generation
software
  - self-hosted adventures
retro
  - physical game collecting
  - game boy hacking
  - retro pc hardware
education
  - creativity in software engineering
  - computing education
...

Articles belonging to a series could simply be added to the chain by a series: key in the front matter. But. Once I got all that working, the overview bugged me: the differences between categories, series, and tags began fading away. For instance, I had a Hugo series, but I also had a Hugo tag. Delete the tag? Broaden the series? More than half of the series seemed to perfectly map to an existing tag. By introducing the taxonomy series, I made things worse, not better.

After a painful git reset, I came up with a good-enough alternative: clean up some of the tags and display a curated selection related to each category in the Archives section to highlight the central themes on Brain Baking. I also added a list of tags in the RSS layout in case feed reader folks might want to start spelunking.

The whole linking system isn't as complex as how I display series of posts on my gaming blog that's also powered by Hugo---where admittedly the whole "series" system was introduced because tags started getting messy. Game platforms replace categories there which makes more sense. That blog is also much more focused while on Brain Baking I like to write about anything that comes to mind.

Obsidian's visualization revealed that I like linking articles together, even though while browsing the archives that perhaps doesn't come across as obvious. I'm still not too convinced. If you have a better idea about handling the big ball of mud called taxonomies, please drop me a line.