@and_yet_it_moves This is an incredibly thorough post, thanks!
This is the most important point for me. Build the core first, then add cherries on top.
Core/basics: Organizing and tagging features, block-scope, usability, solve common bugs
Cherry: Whiteboard1, Flashcard, AI assisted inference, Sharing of knowledge graphs, and others
1: Don’t get me wrong: Whiteboard is a beautifully crafted feature! Only talking about how to invest project time constraints here.
In this regard I’d like to emphasize
and tried to express some of the needed block features:
- Allow to reference blocks in three ways: by ID, name, namespace
- Improve query: Searching for [[page x]] should consider references to blocks inside this page
Current strategy - my take
Just to highlight importance of personal preference in organizing systems, here are examples how I am structuring notes. Basically it’s all about properties.
is-a relation
Boat.md:
extends:: [[Vehicle]]
- boat notes
- ...
Submarine.md:
extends:: [[Boat]]
- Submarine notes
- ...
I value concise, natural page names and rather dislike these long “term trains” from Namespaces. Instead trying to keep it simple and prefering Wikipedia styles: Page name (distinguishing context).
instance relation
Similar to @and_yet_it_moves , I named it instanceof.
Boat McBoatface.md
instanceof:: [[Submarine]]
part-of relation
I also tend to use the part-of relations extensively:
Wheel.md
partof:: [[Car]]
Car.md
extends:: [[Vehicle]]
All in all the properties’ approach allows to dynamically browse through page relations iteratively by looking at linked references, clicking on some link and continuing from here. What currently is lacking:
- graph queries - search through page relations as part of knowledge graph (relations expressed with properties)
- being able to sort linked references of pages, e.g. to give page links in properties higher precedence, to have better overview of relations
- Flexible page layout - and being able to have per-page default queries