Understanding Page and Block Relations in LogSeq (Part 1)

- 3 min read

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.

LogSeq

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:

First-Degree Relations

Block-to-Block Relations (Type A)

  1. Linear Relations: Direct connections through hierarchy
  2. 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)

  1. Containment: A block’s direct relationship with its containing page
  2. 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)

  1. Linear Relations: Direct hierarchical connections between pages
  2. 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:

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:

  1. Block → Page → Page
  2. Block → Page → Block
  3. Page → Page → Page
  4. Page → Page → Block
  5. Block → Block → Page
  6. Block → Block → Block
  7. Page → Block → Page
  8. Page → Block → Block

Simplifying Second-Degree Relations

We can simplify these relationships through several steps:

  1. 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
  2. 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
  3. 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:

  1. Implement comprehensive relation queries in LogSeq
  2. Develop a weighting system for different relation types
  3. 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.