Wiki functionality: Backlinks

Count me in as well: + 1 for backlinks, on Mac and iOS

1 Like

Youā€™ll see that this has been a feature request since 2011. Hopefully this request is starting to generate enough user interest that devs will include that functionality. So, yeah, +1. While Roam slickly integrates backlink functionality, and even suggests other possible candidates as backlinks, it is entirely cloud based and a pale comparison to the full functionality of DT.

It is doable with Applescript.

It wonā€™t anything like in Roam, but good enough.

+1 for built-in automatic backlink listing - Iā€™m afraid I tried the ā€˜manualā€™ AppleScript solution, and wasnā€™t able to make it work. :frowning:

It would be wonderful to go beyond simple ā€˜backlink listingā€™, and actually have DT actively suggest possible connections between items/notes. The approach here could be something similar to the way DT suggests archiving and tags: if there are ā€˜similarā€™ notes that all link to a certain item, then DT could suggest that item as a possible link, too. That would be extremely helpful in finding relationships between notes, when using DT in knowledge-management and research methodologies, like as a Zettelkasten.

The latest Zettelkasten-focused software already offers this functionality in some form - like Obsidian, and Roam Research.

5 Likes

+1

+1 from me too. Iā€™d love to see this.

I agree. It would make DT more powerful and useful.

Same here. Would be incredibly useful.

I would also very much like this function. So pleeeeease?

+1 Would be incredibly useful

+1, this is a really useful feature that would make me very happy not to have to move to something like Roam. I can get similar functionality using apple script, but itā€™s clunky and not optimal. Being able to generate and include backlinks in my docs is a very important feature for the way I take and manage notes.

1 Like

May I be bold and cheeky?

It seems to me the underlying tagging support could support links with backlinks.

A ā€œlink to other itemā€ function could tag the other item with the source itemā€™s UUID.

Showing linked items would be the same as showing a tag group using the source itemā€™s UUID.

To show backlinks, show a search for UUIDā€™s equal to all hidden UUID tags on the current item. That would be a list of source link UUIDā€™s.

Donā€™t you just hate it when some bozo says ā€œall you have to do is?ā€ :slight_smile:

Donā€™t you just hate it when some bozo says ā€œall you have to do is?ā€ :slight_smile:

Yes, but we donā€™t say so out loud.

KIDDING!! :wink:

+1 as well.

Will try out the scripts solution that @Bernardo_V posted but a native solution would be so powerful!

Not to discourage anyone from requesting, but it seems itā€™s not possible to implement this

+1

Actually Wiki links will be supported too by the Document > Links inspector. But other features (like searching for items with incoming/outgoing links or sorting by number of incoming/outgoing links or scripting) will be limited to item links.

5 Likes

Iā€™ve come to realize Iā€™m OK with or without an automated backlinks feature. People seem to believe one needs this functionality for proper implementation of a Zettelkasten.

However, the most famous user of a Zettelkasten, Niklas Luhmann, did this with Zettel on paper. He had no automatic backlink function, and still, his Zettelkasten worked so wonderfully that we all want to have a Zettelkasten ourselves. So either a Zettelkasten doesnā€™t need automated backlinking or Luhmann added backlinks manually.

And Iā€™ve come to realize that adding those backlinks manually might have a point: you need to read the Zettel linked to and write a sentence why it links back, which means you have to think about the linking and the linked-to Zettel and read them and this is the intensive engagement with your Zettel that drives the value of your Zettelkasten.

Doing it manually, you have to read both Zettels. Doing it automatically, thereā€™s the option to read them both, which is a difference.

So Iā€™m going to be fine either way, doing it manually for now.

1 Like

Iā€™m glad I misunderstood that. Thatā€™s great!

Yes, backlinks are not really a requirement for a Zettelkasten, but neither should there be a dogmatic definition of the ZK. One could equally say that since Luhmann did just fine with a paper version, taking it digital is unnecessary. No, Luhmann did not have that option, and neither did he have the possibility to implement automatic backlinks. We can only speculate how he would design his ZK in 2020. My guess is that he would make use of all new techniques that make his workflow smoother, as long as they donā€™t diminish the intellectual engagement with the ZK. Iā€™m curious what he would think about auto-generated wikilinks. To me they are the worrisome ones, because they create connections without engagement. Backlinks, on the other hand, are ā€œjustā€ a consequence of having made deliberately a forward connection. In my view, that justifies autogenerating them.

I started making manual backlinks, which is fine. As you mention, in principle it could be even beneficial, since you have to mentally engage with both notes when implementing them (even though, if you create them in pairs, you have just dealt with both notes to begin with, so the engagement is already happening). However, each of us has a threshold where doing a certain task becomes too cumbersome, and we start shying away from it (ā€œOK, Iā€™ll add the backlinks on the weekendā€ āž aka never going to happen). In my case, I believe that I would struggle in the long term to keep manual backlinks up to date.

3 Likes