This is my second brain, organized based on the idea of a Zettelkasten.
It's implemented using Obsidian application. To use all features (e.g., MoC) it should be viewed in that application.
Nonetheless, since Obsidian uses markdown files, it can be viewed in any markdown viewer, including the embedded rendering of GitLab, GitHub and the preview in IDEs like VSCode.
Yes, there are already many templates to implement a Zettelkasten with Obsidian (or in general using markdown). I took example from some of them and built my personal setup, fitting my personal workflow.
This repo started as a collection bin of many different bit and pieces of knowledge I wanted to write down for myself. To make them easier to be found again, I experimented with the Zettelkasten method. So, this is not, and not intended to be, a comprehensive How-to or tutorial or something like that. It's just a set of small bits and pieces you may find useful.
As said earlier, it's my personal implementation of a second brain. Still it could serve as inspiration for your own second brain. It's definitely not perfect and may even cause issues. So, be aware and careful re-using it as-is.
The files in this repository are created and maintained using obsidian.
Most important community plug-ins
tasksobsidian-tasks by obsidian-tasks-grouptemplaterTemplater by SilentVoid13
Using YAML representation of file properties starting with a --- in first line and closed with ---.
Used to filter notes. Main properties are
- type: type of notes (content, source, moc, project, template)
- status: maturity of note (initial, minor, major) or status of project (backlog, active, simmering, done)
- pending_todo: flag if tasks need attention
- moc: specifically for content notes - list of links to MoC it should be shown (might be multiple)
- tags: what it says
All other horizontal rulers should use *** (not ---)
bases are specific files (.base) in YAML format to create lists of notes fulfilling filter criteria (e.g. type = content) and show specific set of properties. This could be build-in properties (e.g., file links, file name, folder, size) or customer YAML properties (e.g., type, status, pending_todo)
Create views by adding view-specific filter and shown properties. By duplicate view a kind of templating and more and more specific views can be established.
E.g., the base 01-Areas list all notes having type content but not type template. Specific view per MoC filters additionally notes that links this MoC.
A link to a base (and view) embedded in any note realizes a dynamically updated ToC / MoC.
![[<base-file>#<view-name>]]
![[01-Areas.base#Smart Home]]
With an unsorted list with format - [ ] task-to-do, supported by Obsidian community plugin Tasks (see GitHub - obsidian-tasks-group/obsidian-tasks: Task management for the Obsidian knowledge base.), you can place to do's anywhere in any note and monitor / manage them centrally.
Using different type of notes, identified in YAML property type
Beside standard properties (type, status, tags) in the front matter, an embedded link to the base 01-Areas and view specific to the MoC (e.g., `![[01-Areas.base#Smart Home]]')
Footer may contain link to higher level MoC (e.g., git is part of tools)
Main note type to store knowledge. Front matter YAML property moc specifies in which MoC / MoCs the note should appear.
Pending_todo indicates if tasks required attention. (Separately to use of tasks)
Used to create actual notes. Should contain all possible values for properties of list-type, so it can be chosen correctly when instantizing to a specific note.
Due to a line like <%* await tp.file.move("/<target-folder>/" + tp.file.title) %> in the template for project, source or moc all newly created notes are moved into the correct target folder.
Describe a specific project which might use knowledge (content notes) from different areas (moc)
Footer links project to area / MoC
uses project_status instead of status as for other note types to enable different set of status for projects.
Abstract and evaluation of a specific knowledge source. This can be something like a article, web site or YouTube video.
Tasks / to do might be e.g., to deepen or recap some concept seen in that source.
The front matter YAML properties are either only shown in source view (in GitLab rendering) or completely hidden (in VSCode preview mode).
internal links like [[<other-note>]] are interpreted by GitLab / GitHub preview as wikilink, so will lead to a not existing page. VSCode don't render them at all but show them as source code
bases are not supported by either GitLab / GitHub or VSCode preview