Skip to content
This repository has been archived by the owner on Jul 6, 2021. It is now read-only.

Parenting (Notes Hierarchy) #5

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Parenting (Notes Hierarchy) #5

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
703d138
Initial upload
Aug 4, 2020
87aee35
Adding info about parenting the 'root' notes
Aug 5, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 85 additions & 0 deletions docs/0000-parenting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
---
Start Date: 2020-08-04
RFC PR: (leave this empty)
Foam Issue: (leave this empty)
---
[[index]]

# 0000 Parenting (Notes Hierarchy)

## Summary

I suggest implementing a concept of parenting (visual notes hierarchy): when every note can be a parent and/or a child and the same notes may appear in different parent/children trees. There may be a special children view (similar to backlinks explorer) and some special hierarchy visualisation.
In general, this is a convenient folders system replacement (one note can be child of several parents).

## Basic example

This concept is brilliantly implemented in [Supernotes](https://supernotes.app) and [Trilium Notes](https://github.com/zadam/trilium) (for example).
Imagine set of notes collecting quotes from favorite books:
```
Author Name
Another Author Name
Book Title 1
Book Title 2
Book Title 3
Quote 1
Quote 2
Quote 3
Quote 4
Quote 5
Quote 6
```
In flat notes list these notes are looking like a mess. With parenting they may look like this:
```
Author Name
|-- Book Title 1
|-- Quote 1
|-- Quote 2
|-- Book Title 2
|-- Quote 3
Another Author Name
|-- Book Title 3
|-- Quote 4
|-- Quote 5
|-- Quote 6
```
`Author Name` and `Another Author Name` are roots. There is smth like `parent: Author Name` in the metadata section of `Book Title 1` and `Book Title 2`. There is `parent: Book Title 1` in the metadata section of `Quote 1` and `Quote 2`. There is `parent: Book Title 2` in the metadata section of `Quote 3` etc.

In the same time the 'root' notes `Author Name` and `Another Author Name` can be children of some other note(s) (say, `Reading`).

It should be possible to add more than one parent to a note: `parent: Software, Programming`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like that multiple parentage would be better described as [[links]] or as #tags. We know from programming languages that multiple inheritance gets messy quickly, and that trees are simpler than graphs.

For simplicity, I'd propose that parenting allows every note to have only one parent. That will make visualisation significantly easier, too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I fully understand that implementing multiple parents is much more difficult. But having multiple parents seems essential to me: this is one of the main benefits of parenting comparing to a plain file/folder hierarchy, where one note can reside in one and only physical location.


## Motivation

Wiki links are great, but they are not representing the hierarchy of the notes. And when we are putting notes in foders/subfolders there is a need to create a special notes-placeholders, which exist to collect a backlinks. For example, if you keep your travel notes in `Travel` folder, there are good chances, there is a `Travel` note in this folder, which keeps all of the backlinks from all other travel-related notes.
Another one drawback of using folders is that you can't have the same note in several folders without phisically copying it.
Implementing parenting allows you to keep notes hierarchy clean and effective, while using wiki links for adding semantical context.

## Detailed design

The obvious way of implementing parenting is that the parent-relationship info could be stored in frontmatter metadata at the top of the file: `parent: Other document`. That could be made click-navigatable in the document, and we could build features on top of that:
- Visualisation of the hierarchy
- Children view (similar to backlinks explorer)
- Whatever is needed

There should be a way to ***hoist*** notes: being able to focus on/zoom into the specific note (using the specific note as the root of the hierarchy).

When you are in the middle of notes hierarchy (for example: `Author Name` > `Book Title 1`), the newly created notes should be created in the current context (`parent: Book Title 1`), until user explicitly specified another location.

Drag and drop to change the parent notes?

## Drawbacks

Using parenting makes file explorer almost obsolete and may be confusing to the users, which are too tied to using files and folders.

## Alternatives

There may be a way to implement hierarchy in it's simplest form using just wiki links. For example, we may decide, that note, which has a link to other note is a child of the latter note. So the previous book quotes example may look like this:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest that a way to annotate a link between two pages solves note hierarchy and also affords more complex linking between notes (e.g. multiple links, each one with different semantic meaning).

The markup could look something like this:

[[some-other-page?Some context about why this link matters]]

I don't think that's a great way to do the markup, but it would work. An alternative would be:

![[some-link]] Metadata goes here adjacent to the link

The ! preceding the link on a newline would clue that this is an outbound link to the some-link page, and metadata goes adjacent to the link describing an edge.

Copy link

@nixsee nixsee Aug 26, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the first suggestion since ![[ ]] is already use for embedding an image in markdown and even the text of the linked note (if not in Foam - not sure - then certainly in Obsidian, Markdown Memo, and others). Also, I don't think having the metadata outside of the link would work since links are often (generally) in-line.

Whatever the specific implementation, I think it will be crucial to have it be mapped to an actual field, rather than just be descriptive text - a field could be filtered and otherwise operated upon. Perhaps even multiple tag-like fields could be included within the metadata section

e.g. [[some-link?$relationship:parent;$compatible:true;$comment:some context about the link]]

Autocompletions within this would be even better!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw the conflict with ![[]] by chance after posting this.

Finding the right balance between technical rigor (multiple tag-like fields linking two notes) and ensuring the markdown is human friendly should be a first-order concern.

Dendron has an interesting approach to references which would be more readable for complex/multi-property links than trying to inline it all in one link.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed - simplicity/human-friendly is key. Unorthodox file naming is why I was turned off of Dendron to begin with, but looking at it again, it is pretty impressive tool... I may have to explore some more.

Copy link

@nixsee nixsee Aug 26, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked it out. Some very cool stuff, but I don't like the highly rigid hierarchies. I've submitted an issue to ask if it is possible to ditch the "."-delimited hierarchies and use the front matter for parent/child relationships, but I suspect the answer will be no.

That's another option here: don't put the link metadata in the actual links, integrate it with the front matter/link references/however Foam ends up handling links. You could just manually add

title: xyz
date: 2020/08/26
parents: abc, def
children: 123, 789

---

Content

Since it would hopefully/need to be integrated with Foam's internal link management, perhaps when you enter an in-line link to [[note123]], there could be a popup with text fields for each attribute that allows for multiple auto-completed or comma separated entries.

Here's a similar example from TickTick, my task manager.

image

After you've added some, it shows them all as checkboxes when you go to edit again:

image

Something similar could be done in Foam, except instead of Tags, it would be (or could also be) Parents, Children, Compatible True/False, or any other defined attribute. The GUI would put the relevant data into the backend database and perhaps as well into the YAML front matter. Of course, you could edit directly in the YAML, but data integrity (e.g. spelling) would be an issue, whereas a popup tool could have autocomplete/validation built-in.


`Author Name` and `Another Author Name` are roots (they have wiki links to 'Reading' note). There is a link `[[Author Name]]` somwhere inside `Book Title 1` and `Book Title 2` notes. There is a link `[[Book Title 1]]` somewhere inside `Quote 1` and `Quote 2` notes. There is a link `[[Book Title 2]]` somewhere inside `Quote 3` etc.

This is much easier to implement, but may clash with bidirectional links.

[//begin]: # "Autogenerated link references for markdown compatibility"
[index]: index "Foam RFCs"
[//end]: # "Autogenerated link references"