Understanding Page and Block Relations in LogSeq (Part 1)
LogSeq is a powerful outliner-based note-taking app that organizes information through pages and blocks. Understanding how these elements relate to each other is crucial for effective knowledge management.

Basic Concepts
At its core, LogSeq’s structure revolves around two primary elements: pages and blocks. A page serves as a container that can hold multiple blocks, while blocks are the individual units of information. These elements can form various relationships:
- Pages can contain multiple blocks
- Pages can reference other pages through metadata or block content
- Blocks can reference other pages or blocks through metadata or content
- Pages can form hierarchical relationships with other pages
- Blocks can create nested structures through indentation
First-Degree Relations
Block-to-Block Relations (Type A)
- Linear Relations: Direct connections through hierarchy
- Content References: When one block mentions another within its content
Note: Metadata references between blocks are rarely used in practice, so we exclude them from our analysis.
Block-to-Page Relations (Type B)
- Containment: A block’s direct relationship with its containing page
- Content References: When a block mentions a page within its content
Note: Metadata references for pages are excluded for simplicity and consistency.
Page-to-Page Relations (Type C)
- Linear Relations: Direct hierarchical connections between pages
- Metadata References: When one page references another in its metadata
Note: Content references for pages are excluded since page entities cannot hold concrete content bodies.
Analysis of First-Degree Relations
Each type of relationship has a specific number of possible routes:
- Type A (Block-to-Block): 2 routes
- Type B (Block-to-Page): 2 routes
- Type C (Page-to-Page): 2 routes
These form the building blocks for more complex relationships.
Second-Degree Relations
Second-degree relations emerge when two elements are connected through an intermediary. Initially, there appear to be eight possible combinations:
- Block → Page → Page
- Block → Page → Block
- Page → Page → Page
- Page → Page → Block
- Block → Block → Page
- Block → Block → Block
- Page → Block → Page
- Page → Block → Block
Simplifying Second-Degree Relations
We can simplify these relationships through several steps:
-
Converting to Type Notation:
- Block → Page → Page becomes Type B → Type C
- Block → Page → Block becomes Type B → Type B
- Page → Page → Page becomes Type C → Type C
- Page → Page → Block becomes Type C → Type B
- Block → Block → Page becomes Type A → Type B
- Block → Block → Block becomes Type A → Type A
- Page → Block → Page becomes Type B → Type B
- Page → Block → Block becomes Type B → Type A
-
Removing Duplicates:
- Type A → Type A
- Type A → Type B
- Type B → Type A
- Type B → Type B
- Type B → Type C
- Type C → Type B
- Type C → Type C
-
Eliminating Order Significance (since query predicates treat relationships symmetrically):
- Type A → Type A
- Type A → Type B
- Type B → Type B
- Type B → Type C
- Type C → Type C
Analysis of Second-Degree Relations
The total number of possible unique pathways can be calculated based on the available routes for each relationship type:
Total: 2 × 2 × 5 = 20 unique pathways
This analysis helps us understand the rich interconnectedness possible within a LogSeq knowledge base.
Future Development
To make these relationships more practical and actionable, we plan to:
- Implement comprehensive relation queries in LogSeq
- Develop a weighting system for different relation types
- Create evaluation metrics for pages based on specific criteria
This framework will enable more sophisticated analysis of note relationships and help users better understand the connections within their knowledge base. Understanding these 29 unique pathways will be crucial for developing meaningful metrics and weights in future implementations.