Data structure in logseq

[np1]

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

[alex0]

Hi,

@np1

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

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:

Different ways to structure data

Here there are my understandings so far of data structures available on Logseq, feel free to comment and eventually correct me: More than the “pages are collections of blocks” I like “pages are blocks with a name”. We have indentation to create hierarchies between blocks. Indentation of blocks can create hierarchies between pages too, the trick is using blocks containing only a reference to a page: - [[Parent]] - [[Child]] - [[Teddy]] - Some text (eventually) E…

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.

---

@np1

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?

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.

[mentaloid]

Welcome.

---

On simplicity

@np1

I want to build a simple data structure to organize my notes

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

@np1

Aren’t these ideas unnecessarily complicated for regular users?

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.

@np1

but I’m still confused

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

It is your needs that determine how simple you can go.

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

In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away

---

On convenience

@np1

Why should I use links and tags when metadata seems better way

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.

@np1

better way for retrieval data with queries

Isn’t the idea of Logseq and similar software to retrieve old knowledge faster and easier through queries?

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:

Knowledge is a form of data, but quite different than other forms.

---

On the rest

@np1

Has anyone used the graph to retrieve a note?

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?

@np1

Do Logseq developers recommend a specific data structure as the best way to work with data?

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.

@np1

After reading a couple of topics and opinions, I found that […]

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

Neither rely on others’ truths, nor make your own truth. Rather make truth your own.

[np1]

I really appreciate you taking the time to answer my questions

@alex0

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.

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.

@mentaloid

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

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.

[alex0]

@np1

In my opinion, if Logseq allows us to assign multiple values in one property

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

@np1

we can greatly reduce the need for creating numerous empty pages,

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.

[np1]

@alex0

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

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

@alex0

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.

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

[alex0]

@np1

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?

[np1]

@alex0

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

[alex0]

@np1

i mean What is the reason for using both links and properties if they serve the same purpose?

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:

          key
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.

[np1]

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
With::APersionOrAcompany
Subject::
status::done

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

[alex0]

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.