Just installed logseq today: want to jump in -- pages or blocks?

I was motivated to seek (seq?) a notes database facility by the need to record and organize notes, links, material copied from web pages, etc., on a few projects/topics. I’ve spent a few hours reading logseq docs and watching youtube videos. In my head I have a rough outline which has three or four main topics corresponding with current projects. Each of those has a few subtopics, and some of those have sub-subtopics.

As a long-time programmer I’m used to the idea of pages, i.e., files. Blocks are new to me, and I don’t understand their use or whether they’re important. Should you use blocks or pages in LogSeq? didn’t help much. It seems that blocks are “just” paragraphs on a page and are thus a necessity; wouldn’t a page without blocks be empty? Yes, blocks have their own links – as may points within an HTML page.

In my experience with any new undertaking there’s a point of maximum confusion, and I don’t think I’m even at that point yet!

2 Likes

I totally understand your confusion. Like you, I had a difficult time at first wrapping my mind around the difference between blocks and pages.

However, when I realized the huge potential that Logseq presents, but that the learning curve was a bit steep, I decided to invest my time in reading everything in the documentation, the unofficial documentation, youtube videos, the community hub, the forum, the discord channels [I just lurked for months and gleaned as much as I could from the issues others were having]. I also started experimenting with the examples given in all of these sources; trying to understand why they worked they way they did; or why my attempts to do something didn’t work. I also discovered that I had to re-read / re-watch things several times, because as my experience and understanding of Logseq grew, I gleaned new insight into what these resources were sharing. [I didn’t ‘get-it’ the first few times! Boy, did I feel dumb!!]

I also took, and highly recommend, @Dario De Silva’s Master Logseq Course, as well as participated in the Logseq Query Mastery Sprints hosted by @Ramses in the forums.

I can tell you the investment in time and effort to overcome the learning curve is very much worth it.

The people here on the forum and in the Discord channels are extremely helpful and friendly. If you post specific questions about things you’re trying to achieve, you will probably get helpful responses.

With respect to empty pages … a benefit is at the bottom of the page where the linked and unlinked references show up. For example, if you tag a block on any given page, or journal page, and you go to the empty page, the links will show up in those sections. This is why learning to tag and link things is so important - it’s the key to finding the information you put into your graph.

I’ve referred to a lot of resources and don’t want to clutter the thread, so if there is something you are unable to find, just message me and I’ll be happy to share the links I’ve collected along the way.

Also, if you choose to use namespaces, you’ll find a “hierarchy” section at the bottom that gives you links to everything that you’ve created under that given namespace. I use this option pretty extensively in my research and note taking.

Welcome to Logseq and enjoy the journey!

4 Likes

Hi @AgedLace , great answer.

Can you share a good source to learn tagging and namespaces?

Thanks!

1 Like

Hey there @ariekr! Welcome to Logseq.

The key to learning tagging is crucial to jumpstarting, and getting the most out of, your logseq experience.

The most useful resources for me in the beginning were OneStutteringMind’s [@Dario de Silva] beginners course as well as @Ramses basic intro to the Mastering Query Sprints on the forums. Particularly Lesson 2.

With respect to namespaces, the resource that really started to make things click for me was another thread on the forum. There are a few other threads on the forum with extensive discussions on namespaces which may also prove helpful.

Also Aryan Sawhney’s youtube videos were very helpful.

Hopefully, these will help get you started on your Logseq journey!

2 Likes

@AgedLace Namespaces?!? That’s the first I’ve encountered the term (w/r logseq). I didn’t find it in docs.logseq.com but a search led me to Aryan Sawhney’s The ULTIMATE Guide to Namespaces in Logseq | Beginner to Expert – you mentioned him in your reply to @ariekr. That’s an intriguing approach.

I’ll also look at the thread you mentioned. Then it’ll be time for me to click the “Chooses a folder” link on the app’s Welcome page and get started. Thanks so much for your generous help!

1 Like

Glad to help in any way I can. I’m still learning, too, but I’m just trying to ‘pay it forward’ to others who are starting out on their Logseq journey.

Here’s another good place for good info on Logseq, including some how to’s …

https://github.com/logseq/awesome-logseq

I use this approach:

  1. Blocks contain the information.
  2. Pages are blocks with a name.
  3. Pages serve as nodes in the knowledge graph.

that lead respectively to these:

  1. Write single pieces of information in blocks: they can be sentences or paragraphs and use indentation to add structure.
  2. If for you a block needs a name, then use a page to store its information: the blocks on a page are just like child blocks for a parent block. So think about a page like a block whose content goes directly in child blocks.
  3. Use [[wikilinks]] to links blocks together and let Logseq create a so called Knowledge Graph.

Also use properties:: both in blocks and pages to create a relational database: this and graph databases are generally seen as competing data structures. In Logseq you can use both and write powerful queries with [[wikilinks]] and properties::.

Use namespaces only when you need to reference a page with a name that makes sense if referred to another, for example:

- [[My book/Chapter 1]]
- [[An online course/Lesson 1]]

or for compactness:

- [[My book/1]]
- [[An online course/1]]

Notice that those are both pages named “1” but are different pages about different things. Do this only if you need to mention [[Parent/Child]] somewhere else, like you would do in point 3. Otherwise indenting blocks in the same page is enough.

A lot to absorb and think about.
TODO decide whether to use the daily journal as the top level;
TODO learn about queries.

BTW, what is the difference, if any, between–

    [[Parent]]
        [[Child1]]
        [[Child2]]

and–

    #Parent
        #Child1
        #Child2

Is the indentation significant in the latter?

#Page is just an alternative syntax to [[Page]], handy to reference pages with single-word name. No difference.

I was reading your approach with interest but I feel that this somehow begs the question, which is now “why a block needs a name?” instead of “pages or blocks?”.

Because you want to reference that block using its name and create a node in the graph. For example:

- [[The Picture of Dorian Gray]] is a book written by [[Oscar Wilde]]

this creates two pages and nodes in the graph.

Generally a block has content, properties and children:

- Block content
  property-key:: value
  - Child
  - ...

instead a page has a name, properties and children:

Page title
property-key:: value
  - Child
  - ...

With these references nodes in the graphs are linked together and the distance is determined by how many times pages are mentioned together.

To better understand when pages are mentioned together remember these cases:

- In this block [[apple]] and [[banana]] are mentioned together

The following blocks then:

- [[Fruit]]
  - [[Apple]]
  - [[Banana]]

is the same of:

 - [[Fruit]] [[Apple]]
 - [[Fruit]] [[Banana]]

Because [[references]] are inherited between parent and children blocks, so [[Fruit]] is referenced together with [[Apple]] and [[Banana]].

And consider a page name as a block that as content has only a reference to the page it self, so this page:

Fruit
- [[Apple]]
- [[Banana]]

is the same of the following block:

 - [[Fruit]]
  - [[Apple]]
  - [[Banana]]

This is how a knowledge graph is created: linking together pieces of information adds context and a structure emerges.

This is how Google understand that “apple” in “new apple earphones” is different from “apple” in “apple pie recipe” and it’s also how recommendation algorithms (like suggested videos on YouTube) work: in YouTube graph videos are the nodes and the information is videos a user watched. With Logseq syntax it would be:

- Alice watched [[Video X]], [[Video Y]], [[Video Z]]
- Bob watched [[Video 1]], [[Video 2]], [[Video 3]]
- Charlie watched [[Video X]], [[Video 1]]

These videos are then suggested to Charlie: Y, Z, 2 and 3.

I noticed that #foobar is rendered in much smaller type than is [[foobar]].