Difference between #pages [[pages]] and using UI to create a page with heading "pages"

Questions & Help
1

So I’ve spent 3 days on this and even with all the youtube videos I find that people know something that I don’t fundamentally understand… still unfortunately. So I figured I would just let the internet shame me into an explanation. So gentle folks can you kindly help me understand because youtubers seems to talk about logseq with such awe and fascination and I’m in a very confused place.

Goal: What I am trying to achieve.

  • take my Obsidian/Joplin markdown university notes and convert to this format of thinking.
  • so if I start out with clearly defines headings which already exist… and I copy a block; the reference is this cryptic long alpha-numeric code… are you guys converting each heading into a page for easy referencing?

I would love to have a real conversation around this to grasp these concepts.

2

That’s what I do. And there is a plugin for it, called “Block to page”.

(I once tried manually creating a readable reference id for a block, like I would do in Obsidian, but the id would eventually revert to the random alpha-numeric form.)

If you turn a block into a sub-page and still want it to appear as a part of the original page, you embed that sub-page into the main page. You can embed a whole page as a content of a block, with {{embed [[page name]]}}. This page name will be displayed like a heading (bold, and clickable), and (unlike in Obsidian) its content will be displayed as an editable field, so that you can modify this sub-page’s text without click-opening it. This effectively allows you to have a page split into different sub-pages and still unify them as though they weren’t separate pages, in one editable environment, as one document. (Theoretically you could have just one Logseq page to display all your Obsidian notes and their splits as directly-editable blocks.)

Logseq pages are essentially independent blocks that may or may not be embeded into each other. They are “pages” in the sense that they can be individually named and exported. Non-page normal blocks are bound to whatever page they are segments of (as the equivalents of paragraphs or list items in Obsidian), and get a random id instead of a name.

As does Obsidian, Logseq has each page as a node of the graph (-- the collection of the Markdown files in the pages folder) that you can see in the graph view. Blocks don’t appear in the graph view. So, a reason to page-ify a block, additionally to giving it a name for easy referencing, would be to view its reference relations in the graph view.

So, one good approach to Logseq would be to not be strict about “page vs block” as the equivalent of the traditional “document vs paragraph” scheme. If a block becomes referenced, the block is that more important and may deserve to be a unique node in the graph, to be what Logseq happens to call a “page”, and we may consider it to be essentially still a block containing other blocks. To harness the power of Logseq, you want your headings to each contain the paragraphs as children blocks rather than just preceding them as parallel blocks; each heading text is then what summarises its children blocks, just like a page name summarising its content blocks.

Concepts relevant to page and block:

Blocks, in a page, may share the same metadata as page properties, or they each can have unique attributes as block properties. Page properties and block properties are analogous: both are sets of keys and values you can customise to identify whatever collection of texts at whatever level of content hierarchy: the page as the top, and the blocks as different parent-child levels. Child blocks inherit their parent block’s properties, and all of them inherit their page’s properties.

These properties can be set in the form of key:: value, in the page’s first block for page properties, and in any other blocks for block properties. Otherwise, without the keys, the values correspond to #value that can be inserted anywhere. The key-value relation may sometimes be equivalent to the nesting of tags like #parent/child, a form available in Logseq. For example #status/completed can be status:: completed. So, when converting your Obsidian notes, you can keep the nested tags as they are, or perhaps some parent tags could be turned into keys to make groups of page/block properties.

(You can use these properties/tags to also format the texts. You can have custom keywords to create particular types of pages/blocks and target those types with CSS to change their fonts, colors, line-heights, etc, as in a word processor.)

2 Likes
3

this is perhaps one of the most thorough answers I have been looking for and maybe its been answered before but I wasn’t able to find it ; I’m really appreciative of what you typed here. I’ve read it a couple times , there is a lot to unpack here. After letting it simmer with me I have a few more questions that have no spawned in my mind, if you have the patience to stick with me ! (thank you in advance)…

So I have on my graph split the headings into pages… So Page 1 > Page 2 … now when I [[word]] a word or something on Page 2 ; instead of creating a blank page with “word” is it possible for it to reference the entire block instead ? but using the word … kind of like an alias ? and if so how…

my gut says you have already provided me the answer

“These properties can be set in the form of key:: value , in the page’s first block for page properties, and in any other blocks for block properties. Otherwise, without the keys, the values correspond to #value that can be inserted anywhere. The key-value relation may sometimes be equivalent to the nesting of tags like #parent/child , a form available in Logseq. For example #status/completed can be status:: completed . So, when converting your Obsidian notes, you can keep the nested tags as they are, or perhaps some parent tags could be turned into keys to make groups of page/block properties.”

but I just don’t still fully comprehend, and need to see visually so I’m going to start googling

4

There are two ways to reference (have a link to) a page/block by other than its name/id.

Method 1: Use the form []() to link to the page/block.

  • [some text](page name)
  • [some text](block id)

This way, the reference will be displayed as what you write inside []. It’s a non-permanent alias. (Equivalent to Obsidian’s [[page name|some text]].)

Method 2: Set the alias:: property.

  • alias:: some text

This way, you will be able to reference by any custom label a page having that label as the value of alias::. It’s a permanent alias. (Equivalent to Obsidian’s aliases: some text between a pair of --- at the beginning of a page.)

I wish alias:: were available for blocks too, so that we could use it to create a pseudo readable id for a block, to substitute for the random alpha-numeric id; apparently we can’t. Apparently alias:: is only for page properties: the word/phrase after alias:: is usable for linking and searching only if it’s set as the page property (in the first block of a page).

“Reference the entire block”… Any link to a block is a reference to it and its children. For example, let’s say your Obsidian note has a heading “Food” and sub-headings “Fruits” and “Vegetables”, along with all their paragraphs: in order to have them all as one unit for reference, you convert them into a tree of blocks, with “Food” as the parent, the sub-headings as children blocks, and the paragraphs as those children blocks’ children blocks –

- Food
  - Fruits
    - blah blah
    - blah blah
  - Vegetables
    - blah blah
    - blah blah

; then, to reference the entire tree, you create a link to the tree’s top, which is the parent block, “Food” – create a link to that block’s id. To obtain the id, you can first type ((Food)), it will show you a dropdown list of blocks having the word “Food” (any ones in the graph, auto-searching all pages), for you to select the specific block, to get its id. (So you can create a reference to a block easily enough despite its unmemorisable random id, as long as you know what text the block has, as a search term, which can well be the heading text itself.) Otherwise manually you can right-click on the target block’s bullet and select “Copy block ref”. (You can use this bullet to also drag the block around, to even take it out of the page and into another page displayed in the right sidebar. Drag-and-dropping is the way to move a block between pages without losing the block’s id: copy-and-pasting a block creates a different instance of it, for a different id.)

About key:: value and #parent/child…

It’s about how Logseq handles keywords as different identifiers of different pages/blocks. In Logseq, SomeWord (any string of text as a keyword) works as #SomeWord and [[SomeWord]] and SomeKey:: SomeWord, so that you can use the same word as a tag or a name or a property value:

  • #SomeWord – a tag
  • [[SomeWord]] – a name
  • SomeKey:: SomeWord – a property (by a key and a value)

In all three cases, SomeWord represents a link target: clicking on it takes you to the page named SomeWord. To be named SomeWord means to have title:: SomeWord or alias:: SomeWord. The title:: property defines the page’s non-alias main name, every page has this property, and it’s normally hidden, as the value is identical to the page’s title section (the larger text at the page’s top that you can click and modify). If a page’s title section says “Page 2”, it has title:: Page 2 even if this is not shown as the page property.

So, #SomeWord and [[SomeWord]] are equivalent as a link (linking to the page named SomeWord). One difference is when using queries. A query, {{query ...}}, is a custom search that can be inserted into a block to display a particular search result, and you can create a query that searches for a block having a particular tag, #.... A tag doesn’t have to be a page name, it can be a theme of the block, so it can help in searching for one particular block having a unique theme or a set of blocks sharing a general theme. A heading block like “The healthiest foods” could have a tag like #Food/Healthy, and this will be listed in the Linked References sections of the page named Food and of the page named Healthy. As far as making a block listed in that bottom section of particular pages, again #SomeWord and [[SomeWord]] are equivalent: a block having [[SomeWord]] in its text will be listed in the page SomeWord along with any block having #SomeWord.

With tags, the difference between the nesting form #Food/Healthy and the non-nesting form like #Food-Healthy is that Logseq sees the former as multiple keywords (separated by /) and the latter as one keyword. Writing #Food/Healthy means that there may be two pages respectively by those two keywords as names, Food and Healthy, and Healthy will be listed in the page Food's Hierarchy section. This Hierarchy section is an auto-updating list of related keywords. “Related” here means being above or below /, as parent or child. With #Food/Healthy, Healthy is below Food, as a child of Food, as a sub-topic. You can have different hierarchies of the same keywords: along with #Food/Healthy in one block, you can in other blocks use its inverse, #Healthy/Food, so that Food will be listed in the page Healthy, just as #Food/Healthy makes Healthy listed in the page Food. (This flexibility is good, as we don’t always know which topics should go under which other topic.)

So, the form #parent/child is a way to categorise tags. Then, if a category of tags is rather administrative (such as “Status” for Draft and Finalised – something so meta that you don’t want it as a clickable link to a whole page by that word), you can use the property form, Status:: ... instead of #Status/....

1 Like