To link, or not to link

I just started roaming in org the other day. Something I noticed that was tough was finding the right balance between every word being a link and making them only when I had something to at least write a sentence about at that very moment.

An upside of linking even if you can’t spare even a sentence of detail is it feels very low friction to click that link in the future and ‘only add a sentence’ which turns into at least a paragraph.

A downside (or graphing shortcoming) is these things can clutter up the graph.

What rules of thumb do others follow to get the most value here?

P.S. fine with moving this to learn if it’s more on topic there.

3 Likes

The goal of the slip-box is to help you form meaningful connections between your notes. To that end, it’s essential that linking items does not become a chore. Here’s a quote from Ahrens (2017):

It is important to always keep in mind that making these links is not a chore, a kind of file-box maintenance. The search for meaningful connections is a crucial part of the thinking process towards the finished manuscript. [emphasis added]

And here’s another quote on the related topic of treating the slip-box as a mere archive:

The prevalence of linear and learner-centred approaches also lead to the common misunderstanding about the use of the slip-box as a tool that can be used without changing the work routines around it. It is then often used simply as an archive where you just take out what you put in earlier. This, of course, will lead to disappointment. If we are just storing information, there would be no need to use a slip-box. To reap its benefits, we need to change our working routines. And the basis for that is a deep understanding on how and why it works and how the different steps and tasks of writing fit together. This is why a book, not just a manual, is needed to explain the principle and ideas behind it. [emphasis added]

To summarise some other passages in the book, the goal is not to be exhaustive. Creating your notes and your links should be a very organic process, and the tenet it should follow is that of usefulness.

One last quote on the questions you should bear in mind when creating or linking notes:

Every step is accompanied by questions like: How does this fact fit into my idea of …? How can this phenomenon be explained by that theory? Are these two ideas contradictory or do they complement each other? Isn’t this argument similar to that one? Haven’t I heard this before? And above all: What does x mean for y? These questions not only increase our understanding, but facilitate learning as well. Once we make a meaningful connection to an idea or fact, it is difficult not to remember it when we think about what it is connected with.

I hope this helps, and I heartily recommend you to give the book a read if you’re interested in the method.

References

  • Ahrens, Sönke. How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking for Students, Academics and Nonfiction Book Writers, 2017.
6 Likes

I just think about why we link. I link so that I can ensure the note will resurface when I want it to. That is, I link when in some context, I want the note to appear in the org-roam buffer. I wrote about it a bit more here: https://blog.jethro.dev/posts/how_to_take_smart_notes_org/

4 Likes

There were some discussions about adding additional meaning or metadata to links.

I was thinking about differentiating links in - tags :: ... and links in the body where names in the text are added as links, which is quite effortless with org-roam-company.

When I add links in -tags :: ... I want them to show up in backlinks and graphs because I added them deliberately when considering in what context I want them to be found.

Links in the body are for easy navigation and it would also be nice to have them in backlinks in an additional section at the bottom but not clutter the more important backlinks.

1 Like

I guess it is similar to Wikipedia where - tags :: ... would be categories, and links in text would be just links

1 Like

I don’t like the idea of assigning different semantics to links based on context, because users would then either need to make a conscious effort in remembering how to insert the different links, or follow some form of note-taking style.

3 Likes

I have no strong opinion how this would be done, but I think a distinction between categories and links would be helpful. I got the impression there is some work going on, but I don’t know what the plans are.

Tags are coming.

1 Like

Thanks. Now I know what discussion to follow.

I read the discussion in github but -sorry my dev ignorance- I still don’t understand why there is a specially created org-roam node tag #+ROAM_TAGinstead of using the standard org-mode file tag #+FILETAGS.

I would appreciate if someone could explain this to me… °◡°

Thanks a lot…

1 Like

My graph also started to cluster with lots of links and today, I decided to clean it up. The way I did the clean up was to ask the question “Would I click to this link in the future” if the answer is no I deleted that file. In the end, I ran (org-roam-doctor t) to unlink removed files.

For example, I can click to model-free to discover model-free reinforcement learning algorithms in the future but I won’t click to reward for any reason at all. I can click to local optima to see what techniques I can use but I won’t click to action. Though I didn’t remove everything that belongs to no category, for example I didn’t remove policy even though I won’t click to but it may link cool things together.

I like the idea of optionally defining the meaning of a link.

For example, during my PhD, I used concept maps, where named links were a sort of doctrine. In truth, because I was in a hurry, most of my links remained nameless. But sometimes, I found it really useful to give links a name, in order to say something like say “A and B are similar, while A causes C”.

I used to use Semantic Synchrony. It’s similar to org-roam, but it makes no distinction between files and org-bullets. Making a child node is a one-keystroke operation. Giving that child another parent is a matter of copying the child’s address and pasting it into the list of the other parent’s children.

This has the happy benefit that you never have to worry whether it’s worth it to create a link. It’s always worth it, because it costs nothing – the act of giving something content is itself the act of reifying that content.

By contrast in org-roam, because files and org-bullets are different, it really does demand thought. Reifying something into its own file is nice because then it can have multiple parents. But it’s awkward because you can only see backward or forward by one step in the graph. org-bullets allow you to see many levels of structure at once, but all data structured via org-bullets must be a tree, not a general graph.

(I’m using org-roam because I can no longer get Semantic Synchrony to work on my system.)

I’m not exactly sure what you mean by ‘org-bullets’, but if you do mean ‘headlines’, you might be interested in the changes we’ve included in v1.2.0.

Here’s a video demonstrating it:

2 Likes

Well that is cool! Thanks a lot! (And thanks also for correcting my terminology. It’s important to share the same vocabulary.)

What if you’ve linked to a headline and then later decide to turn it into its own file? Or the reverse? It would be cool if that didn’t take a lot of keystrokes.

Linking to headlines still does not solve the problem that links and headlines are fundamentally different kinds of things, and one’s view does not roam :slight_smile: across them seamlessly. Looking three layers deep into a tree of org-headings is a piece of cake; doing the same with links (even if they are links to headings) is basically out of the question.

And even if (when, I’m guessing) we’re able to show a tree-view in the roam-buffer (see org-roam issue 809 on Github; I can’t post the link here because it gets flagged as spam), we’ll still have two incommensurate types of connection.

@JeffBrown, I know what you mean. My current working environment is still one gigantic org-file and one gigantic bibtex file, and when I first constructed it, I had exactly the headlines-as-link-targets questions that you have. My answer was finally <<dedicated targets>>.

With these, you can write a pile of paragraphs, and later, when you go back to them and understand what word or phrase in them was the main idea, you make that word or phrase the dedicated target, and link to that spot from elsewhere. If you rewrite the paragraph, the target can move inside it; if you restructure, and move everything under a different headline, then the dedicated target moves again. Finally, if you do a big rewrite, so that everything under some headline is an elaborated version of your main idea, then you just move the dedicated target to the headline itself. During all of this, all links pointing to the dedicated target continue to work.

In this way, the zettelkasten unit of thought is the dedicated target, not necessarily a headline or a .org file, as it currently is in org-roam.

So, what I’d like to see is dedicated targets becoming another kind of org-roam bidirectional link. It could denote a word, phrase, headline, or .org file, and it could fluidly move between these things. This is somewhat like how Roam Research works.

The problem with the <<target>> format is that it does not allow us to embed an UUID that we could store within the DB. But now that you mention it, it is something that I would like to address upstream in Org-mode. The idea would be to implement the format <<id:$id><target>>, thereby replicating the format of links, but for targets.

This is quite a major change, though, and I’ll need to address it with the folks upstream. But ultimately, now that headlines have been implemented, links to body is the final frontier, and I’d be quite willing to embark on that journey.

1 Like

I’ve discussed the topic with Jethro, and whilst I still thinking it’d be interesting to push this change upstream, I’m not sure if it’d be a good practice to implement in Org-roam.

As Jethro said, when we relate concepts, it’s better to link to a conceptual unit. At first, we imagined those to be files, but it quickly became obvious that having headlines as conceptual units would make it much easier to support different types of notes, e.g., the bibliographic notes taken with Org-noter.

I’m not sure what the benefit would be to be able to link anywhere in a file, even in the body. Functionally, it’s perfectly doable, albeit quite tedious to implement, but I can’t justify the time investment if I do not adhere to the rationale behind it.

So, in other words: convince me! :sunglasses:

2 Likes