Information becomes interesting when you can relate it to other information. But for knowledge to emerge, you need to spark it to life by providing some structure.
Many fans of Logseq like the idea of dumping their thoughts on the Journals page. As you don’t have to think about where to store information, you gain mental space. But what if you don’t know where you left some information that you need now?
If you’ve been using Logseq without caring about any structure, you’ll probably spend more and more time looking for notes. Maybe you even start to miss your files and folders. After all, having some place to navigate to is much easier than traversing a messy outline. Luckily, there is a way to create order in the chaos.
The two main ways to structure notes in Logseq are the outline structure and links (either wikilinks with the
[[double square brackets]] or
Let’s get started by seeing how to properly outline our notes with Logseq.
Logseq is a tool to write outlines. Don’t try to make it behave like any old plain text editor, as the outline structure is fundamental to how Logseq functions.
By nesting blocks underneath other blocks, you create a hierarchy in your notes. Forget files and folders; in Logseq we organize things by branch.
The idea of outlining is simple: anytime you hit the Tab key, the block your cursor is in moves to the right. Indenting a block under the block above creates a parent-child relationship. This is how you fundamentally structure your notes in Logseq:
Let’s walk through the example step-by-step:
- Block A is a parent block; B and C are children of A; block D is a grandchild of A.
- Block B is a child of A and it’s in the same branch as blocks C and D.
- Block C is a child of A and the parent of D.
By indenting blocks, you add context to all the blocks in the branch.
Let’s turn the example above into links and navigate to the linked references of block D, which we’ll name Child D:
By going to the page of Child D, we can see the hierarchy it’s in: first up is Parent and child C and then Parent A. These are the other blocks in the branch that Child D is in.
By clicking on one of the parents, the whole branch becomes visible:
Hey, what’s that? Why didn’t Child B show in the branch when navigating to Child D? That’s because B is a sibling of D’s parent block (C). Siblings are at the same indentation level so they can’t “see” each other in Logseq’s data structure.
Anything that’s higher up the branch of a block can act as a filter value. For example, links. As we’ll see soon, this concept is crucial.
For our purposes (queries), links are like search terms. Anytime you add
[[double square brackets]] or
#hashtags to words, you turn them into a search term you can use in queries.
What happens when you use one or more links in a query? You tell Logseq to read each block in your database. Anytime it encounters the link(s) in a block, it will include that block in the search results.
Why would you use links as search terms instead of plain old text? You could just use text, but using links as search terms allows you to be much more intentional about what results you get.
What’s more, when a parent block contains a link, it applies to all of its children. In other words: every child block will inherit any links and hashtags in any of its parent blocks. This is not possible with plain text search.
But before we get into writing queries, let’s experiment elsewhere with links as filter values.
If you’ve been using Logseq for a while, you may have noticed a Linked References section appearing at the bottom of a page whenever you link to it. This is bi-directional linking in action.
Whenever you link to a page in Logseq, you actually create two links; one that you write, and one that automatically appears in the Linked references section of the page you link to.
Each page has this Linked references section, showing all the blocks that point to that page:
If you have many results showing in the Linked References, it may be difficult to find what you’re looking for. That’s where filters come in, which are a soft introduction to query logic.
Filters can be found next to linked references, which you can find on any page that has links leading to it. You can recognize the filter button by its funnel symbol. When you click the filter button, you see the following pop-up. The shown values are any links (using brackets or hashtags) that are in the linked references:
By clicking a filter value, you include it, meaning that only the block with the value you selected will show on the page. When you Shift-Click a filter value, you exclude it from the page, meaning that any block that contains that value is hidden.
Logseq will remember what filters you’ve set; whenever you return to the page, the filter is still applied.
You can recognize an active filter by its color; when the filter is set to include links it’ll turn green:
When a filter is set to exclude blocks that have certain links, it’ll turn red:
When a filter is set to both include and exclude blocks that have certain links, it’ll turn orange:
Filters are handy when you only want to hide irrelevant results connected to a single page. But what if you want more precisely define your search results, or want to search across multiple pages? That’s why we have queries.
Filters are an excellent introduction to boolean thinking. While we’ll dive much deeper into Boolean logic in the next lesson, I want to challenge you to deduce how queries might work. Linked reference filters are a lot more similar to queries than you might think.
Answer the following questions in writing. Post your answers in this forum thread for today, and take some time to read the answers of others (especially if you had trouble grasping the concepts in this lesson).
- What is an outline structure?
- What purpose do links and tags have in queries?
- Why does the parent-child relationship between blocks matter in Logseq?
- How do only show blocks in the Linked References section that have a specific value?
- How do only show blocks in the Linked References section that do not have a specific value?
Now that we’ve set our first steps with filtering based on links, we’ll start learning tomorrow about how to combine links in ever more complex combinations.
Yesterday over 100 sprinters tuned in live to get a crash course in queries and ask questions about the course. Watch the full replay on YouTube: