Data structure in logseq

Hello everyone,
I’m fairly new to Logseq, and I want to build a simple data structure to organize my notes. However, I’m confused about some topics, options, and concepts.

My first question is: Why should I use links and tags when metadata seems better way for retrieval data with queries? It seems to be easier for me to use and fits more structurally. I’ve read some popular topics here about tags, links, namespaces, and watched YouTube videos as well, but I’m still confused.

My second question is about the graph. Some users talk about the usefulness of the graph and mention that we shouldn’t use a methodology that messes up the graph’s form. Why do we need a graph? Isn’t the idea of Logseq and similar software to retrieve old knowledge faster and easier through queries? Has anyone used the graph to retrieve a note?

I used a hierarchical note-taking application before but I want to switch to Logseq. I tried Obsidian, but I couldn’t get used to it because of the problems it has with blocks. Although there are plugins available, I found them to be immature and not easy to work with. I actually like the iadea of blocks in logseq, which is why I want to switch to Logseq after giving it a try.

In some discussions, experienced users talk about combining tags, metadata, and namespaces to build a good and convenient structure. Aren’t these ideas unnecessarily complicated for regular users? Do Logseq developers recommend a specific data structure as the best way to work with data? After reading a couple of topics and opinions, I found that using namespaces and metadata together seems to be a more convenient way to organize notes.

In the end, I want to emphasize once again that my knowledge about data structure and Logseq is limited and basic.

thank you


Page references and tags are “inherited” by children blocks, this way you can use Linked References and Simple Queries to retrieve blocks according to references in their parent blocks.

The idea is that you just type notes, indent them as it make sense to you and turn some words into page references or tags. It’s a natural workflow but it also populates Linked References sections and Simple Queries in a meaningful way.

You have not to think much about it, but with this in mind you can write a single page reference in some blocks and write stuff in children: those blocks will inherit the references, resulting in a hierarchical organization that resembles files and folders.

For more read this:

Notice that block properties (probably what you call metadata) are not inherited, so you can use queries like (property key value) to retrieve specific blocks and not their children. So you can use properties to complement the structure given by references and tags.

A graph view like that is in general used to see how nodes aggregate. It works well with a lot of data, like the one from social networks i.e. a so called social graph.

As it is now the graph view in Logseq is not much more than a toy, but you can use the Graph Analysis plugin to get a graph like this:

It also lets you color nodes using Simple Queries syntax. This feature makes it actually useful to find specific pages.

1 Like


On simplicity

Almost exactly like almost everyone else: “As simple as possible, but not simpler” (Einstein) than their needs.

In my opinion, there are no regular users, only a wide range (e.g. Different ways to structure data) of different users (with simpler users being the majority, but) with different needs (of no meaningful majority). A good thing about Logseq is that it can fit to more than a single level of complexity, thus covering the needs of multiple users (with different levels of quality). And if your needs change, you won’t have to immediately switch to another application.

Only specific points of confusion can be addressed. In short:

If your needs are met with less, don’t be afraid of dropping the rest (Exupéry):

On convenience

What do you mean by “metadata”? Properties? The key word is convenience. What “seems better way” and to whom? Links, tags and everything else than plain text are also metadata. More limited than properties, but arguably more convenient.

No, it is about managing knowledge. But what do you mean by “better”? More powerful queries? If you want to retrieve with queries exactly what you entered, it is better and faster to use directly a database, not a Knowledge Management System (KMS). A KMS promises more insight with less custom queries (thus easier and more conveniently), but doesn’t compete with the raw power of a database. In short:

On the rest

To retrieve, probably not (although it should be possible and should be made trivial). The graph is for discovering things. Keep an eye on How to leverage Logseq’s linked structure?

More or less, they recommend what they have been developing, i.e. variety all around blocks. The recommended data structure is the block. When working with blocks, imagination is the limit. Does this mean that everything works equally well? No, but nobody has explored everything.

A couple (whatever that means) is too little. Keep finding, by both reading and experimenting:

1 Like

I really appreciate you taking the time to answer my questions

In my opinion, if Logseq allows us to assign multiple values in one property we can greatly reduce the need for creating numerous empty pages, Of course In such situations, you might only see just the information you query for and miss out on the brainstorming feature that Logseq offers, which relies on the interconnectedness between your notes.

Yes, absolutely. You are correct that having the freedom to create a customized and unique database is great. However, some users, and in my opinion, most users, feel that having such a level of freedom makes the software appear complicated, and they worry that they won’t be able to use it effectively and efficiently. And for this reason, it is important to establish a set of guidelines that provide users with assurance that using this method of information management will help them achieve their goal of organizing notes and information for easy and practical retrieval.

we can think of it as a design pattern or a data structure. It’s a suitable approach even for more experienced users who don’t want to trial and error and prefer to reach an appropriate framework.

And When we go beyond a specific threshold of complexity, we find ourselves in a situation where it feels like reinventing the wheel.

When I started using new note-taking softwares, this sense of freedom in the software felt strange to me and still does.

Because ultimately, how much can flawless note management really help us? How much complexity can we tolerate to achieve the simplicity we desire?

Due to this complexity, we continuously find ourselves in a cycle of simplifying and improving our access to information, often becoming more confused in the process.

I want to emphasize once again my knowledge about logseq and data structure are raw and limited

Thank you once again.

Properties already accept multiple values: key:: [[foo]] [[bar]]. Check the documentation for more.

Why would multiple values reduce empty pages? Anyway, pages are not only to store content, they are nodes in a knowledge graph and you can use them like classic tags from other applications i.e. using Linked References section and their filters or the contextual sidebar.

1 Like

when we have x:: foo foo is not a page but x::[[foo]] creates new page as foo

Exactly, and my point is, if we can use properties exactly like [[pages]] why should we duplicate them on new pages, inline, or anywhere else, as long as the graph is useless? Aren’t these repetitions and unnecessary? In my perspective one of these 2 is useless and they can be used interchangeably

Sorry but I don’t understand. What you mean by duplicate them?

i mean What is the reason for using both links and properties if they serve the same purpose? Additionally, links create a separate page for each link and generate a linked reference section for it

A page reference is a link like this:

Block A (on Page A) -----> Page B

and on the graph view Page A is displayed in place of Block A.

While properties are named links or semantic triples:

Block A  ----->  Page B

You are supposed to use page references when writing like this:

- Meeting with [[John Doe]]
  - We talked about [[Project X]]

Since [[John Doe]] is inherited by the child block, you will be able to find that child block both in John Doe and Project X Linked References sections and apply a filter for the other page. Or just write the query (and [[John Doe]] [[Project X]]) to see where you talked about Project X with John Doe.

Block properties instead can be retrieved with queries like (property key value). You can also get all the blocks with a certain property key using just (property key). And then you can display the results in a table with keys as columns and values as cells.

Additionally, as I said above, while page references and hashtags are inherited by children blocks, properties are not inherited i.e. they can be used to find specific blocks.


Couldn’t we create a template of properties for every frequently used structure and use them whenever needed? For example, we could have a meeting template with a predefined structure like below one, along with 5-6 general templates, allowing us to fit our notes into them. Something like zettelkasten method. As I’m typing this, I’m starting to consider the potential limitations and problems of my way to manage notes. I believe I need to spend more time with logseq to gain a better understanding of its idea.

Type:: meeting
Date:: DateInputHere

and everything after that is gonna have(inherited) those 5 properties as well(+indentation obviously)

1 Like

You can create templates of whatever you want.

If you want references to be inherited you can’t use properties. But with Advanced Queries one can even look for blocks whose parent blocks have certain properties.

1 Like