Block reference to allow ((page-name#block-ref-name)) not just UUID

Feedback Feature Requests
4

This is similar to thoughts I’ve had as well.

In my ideal note-taking environment, the note-to-note boundary should be allowed to be fluid, with the note-taking system not enforcing such boundaries. Especially, the file boundary should be abstracted away as far as possible. (The note ↔ file-on-disk connection, for interoperability and future-proofing, could still be maintained.) Handling pages and blocks as similarly as possible would be a step in that direction.

What I write below is similar to what others have suggested above, but I’m taking the chance to present an overview and lay out the arguments.

Now

Currently, LogSeq operates with a tree-structured hierarchy[1] with

  • pages for level 1, and
  • blocks for level 2…N.

E.g.:

                     level
                     -----
* page A             1
  * block A-1        2
    * block A-1-I    3
    * block A-1-II   3
  * block A-2        2
* page B             1
  * block B-1        2

Linking to pages vs. blocks:

entity    level   referenced as
------    -----   -------------
page      1       [[title:: property of the page]]
block     2-N     ((block UUID))

Motivation

This difference is, conceptually, somewhat arbitrary to me. I’d prefer to treat blocks and pages as similarly as possible. This is in line with @deniz notion of treating the blocks as first-class citizens.

Hence, ideally:

entity    level   can be referenced as
------    -----   --------------------
page      1       [[title:: property of the page]]
block     2-N     [[title:: property of the block]]

Suggestion

The link reference for pages is already kind of (allowed to be) separate from the page file name through the title:: and alias:: page properties. The same could be used for blocks - i.e., allowing reference by a title:: (or alias::) block property.

E.g.:

<page A file:>
title:: page A
* title:: block A-1
  some text of block A-1

<page B file:>
title:: page B
* first block of page B
* here, we could e.g. link to [[page A]] and [[block A-1]]

(The user has the option to define a title:: property for a block - UUIDs could also be used, as now.)

This would be the blank-slate ideal implementation. There’s probably aspects I haven’t thought of.

Also, I’m not sure how to handle title collisions, i.e. assuring titles for blocks and pages being globally unique. I guesse LogSeq already has to handle this for collisions on page titles, if defined with the title:: page property, or in any case for an alias:: colliding with another alias:: or page title. Some unified way of avoiding or handling such collissions could be used.

In practice, interoperability with Obsidian weighs heavily as well, and could be a strong reason to choose the Obsidian course rather than my ideal blank-slate suggestion.

Related

  • All existing editors, even the web-based ones, have some hangover from file-based content management. Even with ability to cross-link to nodes inside a tree structure within files, the rigidity of file boundaries is still over-constraining, especially when one is trying to grapple with unfamiliar concepts during which the structure and links are constantly shifting.
  • It should take the concept of knowledge graph as far as possible. The foremost thing is to do away with files, and promote vertices (nodes) and links (relationships) to first-class status.

(from I actually grew really frustrated with existing solutions for organising notes: ... | Hacker News)

[1] a tree-structured hierarchy is defined as

every node is connected to
( (<= 1 parent node) AND
  (>= 0 child nodes)
)
5 Likes