Hierarchies

Summary

Dendron organizes your notes into hierarchies. These are . ("dot" or "period") delimited Markdown files.

Example

Below is a hypothetical hierarchy for a file tree:

.
└── project1/
    ├── designs/
    │   └── promotion.png
    ├── paperwork/
    │   └── legal.md
    └── tasks/
        ├── task1.md
        └── task2.md

The same hierarchy in Dendron would look like the following:

.
├── project1.md
├── project1.designs.md
├── project1.designs.promotion.md
├── project1.paperwork.md
├── project1.paperwork.legal.md
├── project1.tasks.md
├── project1.tasks.task1.md
└── project1.tasks.task2.md

Concepts

In the following concepts, we will be using the following file tree

From Layout

Go to text →

Basic

.
├── dendron.code-workspace
├── dendron.yml
├── .dendron.port
├── .dendron.meta
├── docs/
├── .gitignore
└── vault/
    ├── root.md
    ├── root.schema.md
    ├── dendron.md
    ├── dendron.faq.md
    ├── ...
    └── assets/images

dendron.code-workspace
- VS Code and Dendron configuration
dendron.yml
- Dendron specific settings
.dendron.port
- writes the port that the Dendron engine (Private) is listening to
.dendron.meta
- writes Dendron specific metadata
.gitignore
- add special notes
docs/
- used to generate a static site from your vault
vault/
- root.md
  - generated by Dendron, root of all your hierarchies
- root.schema.yml
  - generated by Dendron, root of all of your schemas
- assets/images
  - default for Dendron Paste Image extension to put images in

Terms

workspace root

From Workspace

Go to text →

The folder that contains files like dendron.yml and dendron.code-workspace is the top-level directory of a workspace, known as the workspace root.

Root

Every vault has a root. This is the root.md.

Domain

The domain is the root of a specific hierarchy. In our example vault, we have one domain - dendron.

Why Hierarchies?

From FAQ

Go to text →

Users of other note-taking tools often balk at Dendron's focus on hierarchies. The common counterpoint is that the real world is not constrained by hierarchy and that this approach isn’t flexible enough for what they want to do. These users argue for graphs and backlinks as a better primary model for managing knowledge.

A graph is indeed more flexible. If we were building a digital brain for computers to perfectly model the world, we would probably go with this approach. But we are not building a tool for computers to capture every facet of the world; we are building a tool to help humans make sense of it. The challenge we face as humans is information overload. There is too much of it and we need ways of constraining that complexity. Filtering large amounts of information into exponentially smaller subsets is what hierarchies are built for (and why they are used as the core primitive in every database ever created).

With a hierarchy, you have one source of truth where a note can be filed and a filtering process to help you find the right place to file. Note that this doesn't limit you to creating secondary associations using backlinks, tags, and keywords.

The traditional failings of past hierarchies were that they were too rigid. Most people’s experience with hierarchies are folder hierarchies that ossify from the moment that they are created. These hierarchies are hard to change and so people don’t change them, even as their underlying understanding of the domain changes. It is because of this friction that most new tools focus on note creation without any predefined structure. This approach makes creating notes easy but finding notes hard.

Dendron has flexible hierarchies. They provide a structure for your notes but these structures can be easily changed. In programming, developers can refactor code and change its structure — the IDE will make sure that all references pointing to the original code are updated. In Dendron, you can refactor notes and hierarchies and Dendron will make sure that your PKM is consistent throughout. This means that you have the best of both worlds: a basic structure for the organization but the flexibility to change it.

What's with the `.`'s?

It allows each file to also be a folder. This means your notes can have data but also contain other notes.
It makes it much easier to perform certain refactoring operations. For example, say you had the following schema
```
- id: a-parent
children:
    - child-a
    - child-b
- id: child-a
- id: child-b
```
Lets say you wanted to make child-b a child of child-a
```
- id: a-parent
children:
    - child-a
- id: child-a
children:
    - child-b
- id: child-b
```
With the classical folder hierarchy, you would need to turn child-a into a folder and then create a custom file to hold the content from the original child-a
```
.
└── a-parent
    └── child-a
        ├── child-a-note
        └── child-b
```
With the . delimited hierarchy, this becomes a simple rename operation
```
.
├── a-parent.child-a
└── a-parent.child-a.child-b
```
It allows us to create stubs for parts of the hierarchy that don't exist and not clutter our file system with empty folders. With the classical folder hierarchy
```
.
└── a-parent
    └── child-a
        └── grandchild-a
            └── great-grandchild-a.md
```
With the . delimited hierarchy
```
.
└── a-parent.child-a.grandchild-a.great-grandchild-a.md
```

Backlinks