Hierarchies

Summary

Within a vault, your notes are stored hierarchically as . delimited markdown files.

Below is a hypothetical hierarchy for a file tree:

.
└── project1/
    ├── project1/designs/
    │   └── project1/designs/promotion.png
    ├── project1/paperwork/
    │   └── project1/paperwork/legal.md
    └── project1/tasks/
        ├── project1/tasks/task1.md
        └── project1/tasks/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 dendron.ref.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
- vscode and dendron configuration
dendron.yml
- dendron specific settings
.dendron.port
- writes the port that the dendron engine 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

This is the folder where dendron.code-workspace is located

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?

Dendron is built around hierarchies and the axiom that a canonical hierarichal representation of notes is one of the most effective ways of managing large numbers of notes. You can read more about the thoughts behind this here.

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
```