Suppose I learned two concepts from a book called A, and turned them into two notes, B and C.
Now I have three notes: A, B, and C. A is the parent of both B and C; B and C are children of A.
How would you connect them?
I think there are 3 ways to do that:
In note A, reference notes [[B]] and [[C]];
In note B and C, use property like “Parent: [[A]]”;
Both 1 and 2.
The 3rd way seems a bit redundant, so would you choose 1 or 2? Why?
Generally, if I have two related notes D and E, should I reference E in D, or D in E? Is there a good rule so that I can follow?
However, your notes are not a DAG (directed acyclic graph). There is no hierarchy. There are no parents or children. Except if you define those concepts through your own naming conventions. Links don’t imply any meaning or structure on their own.
The links do have a direction. But the graph is a bi-directional network. You can link one way, both ways, cyclic, anything you want. There is no best practice here, except what works for you.
If you don’t link both ways, you also have Backlinks: Linked Mentions, and Unlinked Mentions. You can also show Backlinks in-line inside a note. You also have the Local Graph. So if you don’t link both ways, as long as there is one directional link, you’ll have that path to traverse.
There is also a feature request to add link types, which would help us define things like children and parent relationships. (You could also hack together structure by using properties or naming conventions, or restricting yourself to one-directional links.) Add support for link types - #24 by cristian
Indeed as you said, there is no hierarchy for links. I’m also aware that both A to B and B to A work. However, it’s a bit hard to decide which to choose. So I’d like to see how people practice it in their knowledge management.
Maybe it’s better to be able to define link type, so that it would be easy for people like me