I wonder how to treat hierarchy in links, in cases where you use links as kind of tags (and if you don’t want to use tags per se).
For instance: let’s say I add a note which is related to some overarching topic which is in turn related to some overarching field:
note > topic_name > field_name
What links will you add to your note?
Do you only add the link to the next higher level, i.e. [[topic_name]] or do you add links to both higher levels, i.e. [[topic_name]] + [[field_name]].
Of course, the topic will be linked to the field. So the lower level note is still connected to the overarching field, albeit through an extra step - in cases where you choose to only include the link to the next higher level.
I wonder how the usability and structure of my vault is impacted by these two possibilities (‘add only link to next level’ vs. ‘add links to all levels’) and I would love to get your opinion.
Thanks for your question about how to use links to reflect the hierarchichal nature of your data. In my experience, the answer is “it depends.” There’s a lot of tradeoffs to consider when linking your notes in a hierarchy. For example, should parents link to children? Should children link to parents? Both? It sounds like the question you’re asking is: Should children link to grandparents?
The answers to these questions aren’t obvious or universal, because it depends on at least three things:
What questions do you plan to ask of your vault?
What’s the minimum amount of information you need to maintain in order to answer those questions? (e.g. links, tags, folders)
How much work are you willing to do in order to update and maintain your structure as the content of your vault changes?
None of these are trivial questions. I recommend giving them a little thought and playing with a few test pages in your vault to see how they feel, especially what it takes to keep the structure up-to-date as your vault grows and changes. Friction is the mortal enemy of any organization strategy.
If you’d like, feel free to post a little more information about your vault. What are a few examples of your notes, your topics, and your fields? That would help us give some suggestions on how you might organize your data.
I’m just thinking about this question in these weeks.
Linking to grandparents and to parents vs linking to parents only?
Sometimes I’m using the first, other times the second. There are benefits and drawbacks in both.
Currently I tend to use this strategy:
Into the note A, I link to parent only, using a
up:: [[parent]]
in some cases, not always, if I have a MOC (an index note) regarding topic of the note and Moc is grandparent of Note A, I put a link from the MOC to note A too, often creating a tree:
[[Parent note]]
- [[Note A]]
The main drawback of linking grandparent is that the graph becomes a mess. I like having the graph more similar to a tree, instead.
But linking grandparents too makes navigations to note a little better.
I think about it a lot too. Lately I’ve been finding that a very effective organization strategy is to link down instead of up – that is, that parents link to their children, and children do not link to their parents. This seems to be supported best by Obsidian’s out-of-the-box experience.
I am a researcher in ecology and I would like to use my vault for knowledge but also project management.
On the most basic level: I might make a note on new statistical methods, papers I have read, data analysis ideas or project meetings - so these would be examples of the children notes.
On the next higher level I might have parents that are kind of MoCs for certain publication targets, on-going data analysis or fieldwork projects, i.e. [[parents]]
Above that, these smaller sub-projects are usually part of bigger overarching projects (often tight to funding), i.e. [[grandparents]]
And these are all part of my work in ecology, i.e. [[great-grandparent]] (of course there area also other fields/realms of personal interest).
Basically, I would love to be able to go to a higher level anytime and get and overview (MoC sort of thing, using queries or dataview) of what I have been working on recently and what might be current open tasks for each of the respective (sub-)projects.
I think my main aim is to feel more in control of the many things I am working on at the same time - so being able to go ‘higher’ up the chain would be great. Also sometime I might not work on a certain topic for weeks - so the purpose would also to have [[parents ]] as starting point to get back into a topic.
Yes, you can try different Obsidian features for implement parent-child navigation.
I tend to navigate child ->parent more often than parent->child, so I feel more comfortable usind up:: [[parent]] in child notes. But I find very useful top down navigation too, creating MOCS or dataview blocks. I don’t feel comfortable using backlinks, instead.
Consider using Obsidian Breadcrumb plugin, too. I’ve not tested yet, but it could be useful.
It sounds like you have at least two different purposes for your vault:
A reference repository where you can store information you’ve gathered and organize it for later retrieval.
A project management system where you can manage projects, tasks, deadlines, etc.
My work vault has similar multiple purposes. I work in software development, and Obsidian multitasks as my project manager, reference depot, and CRM; and does a good job at all three.
For reference material, I suggest trying a top-down approach, where you have topics that point down to their children, but the children don’t point back up to their parents. For navigation, try looking at Obsidian’s built-in backlinks pane, which will show you all the pages linking to this page. It might be all you need to manage navigation and feel like you know where everything is. This strategy works pretty well for contacts and organizations too.
Project management is a different animal, and it’s hard to give good advice here because everyone’s workflow is different. Right now I treat Projects as “super-topics”, linking down to their associated products, clients, assigness, and so forth. In some of the child pages I use Dataview queries to show which projects are associated with this product/contact/etc. This strategy works well for me, but it’s definitely a work in progress.
I use folders as well as links to manage my pages. I use folders strictly for typing – all my Products go into one folder, all my Projects into another, all my Contacts into another, and then use linking to create hierarchies within and between those categories. This works really well in concert with Dataview, because querying over e.g. all my Projects at once is very easy.
I hope this is helpful. Happy to go into more detail if you’re interested in anything specific.
It seems to be quite common to run into this. I asked literally the same question on discord a while ago and I was supprised to see so many peaple responding and explaining their workflows. My current approach is to accept the idea of huge mocs and making sure everything related is linked together (meaning I would link to the parent AND the grandparent). I’m also a user of the "up:: " section. Here is the link to the original discusion on Discord