Alias property for blocks

I’d like to be able to create pages which redirect to specific blocks.

e.g. I can create a page named Dishes with: alias:: ((62e282ac-5888-4d10-9a40-c7fca33cdd51)) as it’s first bullet. Clicking on [[Dishes]] anywhere in the graph will redirect to the linked block and skip redirecting to the page.

This is useful if you don’t want to separate all your data into so many separate pages, which can make graph traversal more difficult since breadcrumbs are less used.

The opposite would be even better so that there wouldn’t be need to create a Markdown file for an empty page that contains only the alias definition.

So from any block:

- Title of the block
   alias:: [[Title of the block]]

Clicking on any reference to [[Title of the block]] would open the block above.

This would be a killer feature especially if the block is displayed in the Graph View like a page.


@Creator is it OK for you if I rename this request “Alias property for blocks”?

I see I neglected to mention another reason why I use pages here - because they get top priority when using the search bar. If I search for keyword then it might bring up 20 results, but the canonical one I’m looking for is near the bottom rather than near the top.

I’m not sure of alternative way to force a specific block to have the highest priority during search, so I make a Page which just has a Block Reference to that block.

This sounds like a recommendation so that when searching [[Alias to a block]] it actually get the priority of a page, right?

To be clear, your request is being able to specifying the alias inside a page to open a specific block, but then you would have a Markdown file containing only an alias definition for each page-block alias.

Instead, by defining the alias directly in the block, you avoid useless empty Markdown files.

So what do you think about updating title and description to the second approach and mentioning your recommandation about the priority as search result?

Sure, that’s good with me.

I think this is a great idea. Some collaborative, brainstormed thoughts:

  • name property instead of alias, which aligns better with internal :blocks/name attribute of pages. An alias with pages is like a synonym for an already existent title or name.
  • Understand the feature as giving globally unique names to block-like structures (blocks in addition to pages). Syntax [[my block link]] stands for named links and can be used for references of both blocks and pages.
  • “Block-like structures”, because Logseq uses separate entities page and block, which in practise share similarities
  • A block can still also be referenced by ID, which is the point of parentheses syntax ((1234)).
  • Potential pitfall: Users need to learn a third type of organization unit besides pages and blocks: “virtual pages”, that don’t exist as markdown file
  • It raises the question, what a page is in Logseq
  • (Personal stance: I see many benefits with having just blocks for everything in user interface and core application logic. This can be topic of later discussions, as giving names to blocks is overlapping feature)
  • Developers and contributors might be able to discuss best (with feedback from community), what duty a page has in application logic and why/where/whether it is needed as separate unit apart from storage mechanism.
  • Document these new design decisions for users as part of community effort

Do you think this mechanism could be extended to also handle your idea of encoding relationships between tags?
I would love to import my Zotero hierarchy, but it would mean ten thousand pages, one for each tag. 99% of these will never have any content, other than parents, children, and alias.

This would be awesome, i.e. express the relation between pages/tags but they are blocks with an alias!

- Mathematics
  alias:: [[Mathematics]]
  - Algebra
    alias:: [[Algebra]]
    parents:: [[Mathematics]]
    - Linear Algebra
      alias:: [[Linear Algebra]]
      parents:: [[Algebra]]
  - Geometry
    alias:: [[Geometry]]
1 Like