For example, I don’t use a lot of Python, but there was this one weekend, not too long ago, where I binge-learned it. (This was B.O. - Before Obsidian.)
Now, when I want to remember enough Python to maybe parse some JSON from the command line, … I open up my old-school notes and it’s a total mess.
I’ve been really chewing over this one subject all week - what is the best way to break down and organize a large, semi-used topic for rapid “uploading” into the brain?
Here are some ideas I’m kicking around:
Have a hub / MOC / index / register / home page named “Python”
Divide all of Python into a handful of categories and show only those, so no note is longer than about a page-ful
So the top-level hub is made up of only 5 links to sub-notes, that’s it - easy for the brain to quickly get the high-level overview of “What is Python”
Each sub-note has another 5 sections only, either briefly explained or just a link to another sub-note - so I’m keeping each note just large enough to parse easily for a busy brain
Each sub-note links back up to its parent, like a tree
Those are the basics; you get the idea.
What about you? I would really appreciate seeing any examples if you’ve run into this scenario and come up with your own solutions. Of course, everyone’s brain works differently, but still, share if you can! Thanks in advance.
Hi, it’s me again - just thinking some more, but, take my “How to parse JSON with Python” example. How do you make that note atomic (i.e. prepend it with the necessary know-how) when the prerequisite is all the basics of Python?
My note would look like:
How to parse JSON with Python
Prerequisites:
See: [[How to install Python]]
See: [[How to include 3rd party modules]]
See: [[How to write a simple script]]
See: [[How conditionals work]]
See: [[How variables work]]
How to do it:
… JSON lib info goes here …
So that’s why the tree-like structure in my notes, now, is I need to slurp up all the basics of a language / topic just to use a single “downstream” note.
I think your idea would work just fine for all kinds of cheetsheet like notes which contain especially processes you want to come back to later. I have lots of these howto notes for everything from rebooting the raspi that runs our radiators to administrative rules for my vault. They are really handy and I am free to forget stuff I don’t need this very moment knowing I don’t have to look it up/figure it out again later. It’s a wonderful feeling.
I think a combination of PARA by Tiago Forte and LYT by @nickmilo would be the most useful in your case. Kinda like keeping the tree structure true to the PARA Framework, but atomically linking notes using the LYT Framework.
From the different frame works I tried, If you just want to use 1 Framework in Obsidian then LYT works best (Obviously a combination of frameworks is better, but only you can decide how much of each framework you want to bring in your own unique framework.
To Summarize:
To manage your current situation this is what I feel can help you.
If you just want to use 1 framework, then LYT.
If you are open 2 using only 2 frameworks, then PARA and LYT.
IMO Best case scenario is, you try all the frameworks which you feel can be used in obsidian, and make your own unique framework, optimized for you.
@terheyden: yes, something like that could work. But I don’t think you have to include the prerequisites in every note. Either you put them in a higher order note, like a MOC, or at least you put them in another note and link that into your JSON note.
I think for your usecase working with different levels of MOC’s would be perfect. The top note could be e.g. “Python MOC”. In this MOC you link to other MOC’s, like “Standard Libraries MOC”, “Scripts MOC”, “Python and Internet MOC”, etc. In “Standard Libraries MOC” you then can list those libraries with their objects. And link those to distinct notes where you explain them.
One tip: If you want to see an example how to structure your Python knowledge base, take any good Python book and see how it’s structured. You even could look at the book previews in Amazon. There you normally can see the table of contents. Each of the chapters could be a MOC in your KB.
BUT: I think it would be overkill to simply copy the table of contents from a book and create a lot of MOC’s you don’t need. The TOC should only provide an example for the structure. Create MOC’s only for the topics you really want to write about. Just my 2c.
I’ve also implemented P.A.R.A. on Notion and 2 of my cloud repositories.
Since I’ve discovered the “gardener” approach you might apply in Obsidian, It seems like LYT becomes more suitable, but still, I miss the static idea of Actionable vs Non-Actionable that underlies the P.A.R.A. framework as well.
So far I’m just using Tags as “System ones” and using Links for “Topic or Potential new MOC”. But I have serious doubts about which is the best approach combining both (see Different PARA implementations in Obsidian).
Personally, I would like to avoid the extreme use of Folders, just relying on Links for each of the 4 P.A.R.A. categories. Once you unfold Area and Resource instances and try to embrace them from a MOC standpoint… that’s when my headache comes out…
