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.
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?
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 Idea would include being able to lalias blcoks like pages so that if you make changes to one blovk, they would appear in the other one as well, without the need for onw to be an embed of the other one as is my workaround right now, right?