Different ways to structure data

with logseq, is it just as easy to query this kind of hierarchy as it is to query relationships in the namespace hierarchy?

Good question. How do you use namespaces with queries?

At the moment I use indentantion of blocks just for “indexes” like the math example above, so I don’t need to query them. I use properties:: to maximize the usefulness of queries.

I don’t (yet), as I’m new to Obsidian. But it sounds like it’s not possible to do queries taking namespace into account? That’s a bit odd. In Obsidian, it’s normal to be able to search and query with a path: argument, which would be the equivalent.

You need to be more specific and anyway with advanced queries you can do everything since with them you are basically accessing the database Logseq is using internally.

Ok I’ll play with the queries to see how easy it is to write queries taking into account namespace and indentation structure

I kind of wish the section at the bottom of the page was called “Namespaces” then, or “Page Hierarchies”. I also wish there was a “Namespaces” page you could toggle on and off, so it would display a link on the Left Sidebar between Graph View and All Pages called “Namespaces”. Then I’d like to click there and see all the trees of namespaces in my graph.

It’s a bit like a folder view for namespaces, but my brain is more of a foldering one than a tagging one, at its core.


This kind of replicates the folder/tag distinction, in that the Namespaces/Pages/Indentation manner of creating context is structural, and the Page Properties/Block Properties manner of assembling items to view is dynamic.

When using Properties, contextual information information becomes widely distributed. You tag the note to a structural idea but did not follow a browsing path to the point in the structure where you want that note.

One challenge for me here is that building out structural relationships which have some stability (e.g namespaces, folders) and are easily visualized, has great mnemonic value.

For someone like me, the up front decision of “where to put a note” is actually one of the best parts of personal info management. I love it because it’s an up-front investment in developing mental clarity. I’m a structuralist thinker.

The timeline approach confuses the hell out of me. I suppose if I was free to build out my topic-oriented graph, and timestamp entries so that they got embedded into the Journal kind of incidentally, I wouldn’t mind. I hate the idea of working in the Journal though.

If I want to work on my History of Goth Rock page, I want to work on that page, toplogically! I don’t want to work in my Journal and tag it to that page. I’d rather it was the other way around.

Once I start dispersing structural information across blocks in the form of properties, I get lost. I lose my bearing/orientation, and each note loses meaning for me. It only makes sense when I traverse a meaningful path to get there.

Even if the UX is similar, knowing that I have to add properties to a block to get it to show up in the right place, instead of just clicking a stable structure to get there, is disorienting. I lose my trust in the system that way.

tl;dr There are cognitive reasons people might prefer the Namespaces/Pages/Indentation manner of creating context, as opposed to the Properties manner.

If the two were technically combined, some of that tension would ease. If I had a Namespace page that was editable, so I could move pages up, down and around the outline on that page, and this automatically updated a Namespace property, then it would matter less to me.

Or if there was a Hierarchies page, with one root-level “Namespaces” block as a system-provided block, but then you could add Query-based hierarchies below that, this would also be a bit more usable for me.

I have a little hack where I query {{namespace [[Hierarchies]]} on the Hierarchies page itself, and then I put every single page in a graph in the Hierarchies namespace. The page names get brutally long, but at least I have the deep, narrow pathways into the heart of my graph that match the way I prefer to access information.

In Bergman and Whittaker’s book, “The Science of Managing Our Digital Stuff”, they point to research indicating how when it comes to Personal (as opposed to public) information, most people prefer navigating a structure to searching for (therefore remembering) terms.

That may be because you can use procedural memory instead of declarative/semantic memory, or you can rely on recognition instead of recall to access information. Navigational methods activate a large bilateral posterior region of the brain, much of which operates subliminally, to guide info retrieval. Search leans very heavily on Broca’s area.

So the two manners of creating hierarchy Cesar mentioned kind of map onto this navigational vs. keyword-based way of structuring knowledge.


On analogy from other digital tools, I’d say that you combine querying and namespaces by creating something like “Smart Folders”. So you could have a query that returns the Child and Teddy pages of some set of Parent pages - and you could put filters on that.

So I could get everything from my Psychology and Physical Anthropology namespaces that has “Limbic System” in it - then I could put that page in my hierarchy.

Maybe I misunderstand you, but this already exists. You can show the namespace (called Hierarchy in Logseq) both in the main window and sidebar:

1 Like

@Ramses Left Sidebar, for all Hierarchies, was my thought

Logseq is an outliner that’s built on top of a graph database. What you’re proposing sounds more like something for #feature-requests, but it would cause an anti-pattern (back to folder hierarchy).

The hierarchy at the end of the page with all other pages in the namespace is the closest to a folder hierarchy you’re going to get in Logseq. Personally, I wouldn’t obsess too much about hierarchy in Logseq and instead rely more on linking and indenting blocks.

1 Like

We discussed this for a while and here there is our proposal:

I don’t think this is an anti-pattern; namespaces seem to me more similar to folders than the proposal above, that links together properties, queries and hierarchy.

I’m running into a limitation of my technical understanding here. All I can rely on is my own understanding and use of Logseq as a graph tool, and I wouldn’t know why I would want to create (strict) hierarchies in my graph. But, to each their own.

I know @cldwalker is interested in reworking the namespaces, so I hope he’ll have a look at the proposal.

But these are not more strict hierarchies than the ones we already have. It’s just some helping UI/UX.

At the moment when you look at the graph you only see one type of relation, “reference”. We want to embed more information into relations between pages by using properties (already possible) and browse/display it (what we are proposing).

For example you want say [[Linear Algebra]] is a branch of [[Algebra]] that is a branch of [[Mathematics]].

At the moment you have three possible approaches

  1. namespaces:
    [[Mathematics/Algebra/Linear Algebra]]
  • Pro: better navigation with breadcrumbs at the bottom of pages
  • Con: too strict, hard to manage, don’t scale, can’t use the same page in different hierarchies
  1. block indentation:
    - [[Mathematics]]
      - [[Algebra]]
        - [[Linear Algebra]]
  • Pro: easy to manage, edit, update, you can mention the same page in different hierarchies
  • Con: worse navigation i.e. no breadcrumbs like namespaces and in the graph all the relations look the same i.e. no way to specify that the above is a branch-of relation
  1. properties:
   branch-of:: [[Mathematics]]

   Linear Algebra.md
   branch-of:: [[Algebra]]
  • Pro: you can give a name to the relation (“branch-of”), it can be combined with queries, the same page can be in different hierarchies
  • Con: basically impossible to browse, no breadcrumbs, no command to print an indented list like namespaces, no way to display only this relation in the graph view

We are proposing better UI/UX for the third approach that could solve two issues often mentioned by users: graph is a mess to navigate and namespaces are hard to manage.



  • Why is this an anti-pattern?
  • It’s an indented outline!


  • As alex0 says, there need be nothing “strict” about these hierarchies.
  • Think of hierarchies as flashlight beams into your graph.
  • You can have several, illuminating your graph from different angles.
  • A block or page can turn up in several hierarchies.
  • Sometimes you want to look into your graph, and go to a specific place, and start working there.
  • It’s a wayfinding or orientation aid, exactly like Nick Milo’s MOC and Datascope concepts.


  • It’s fine if most of the pages in my graph don’t show up in this MOC-type of view of namespaces.
  • I don’t intend this hierarchical “net” I’ve thrown across part of my graph to be exhaustive.
  • I’d expect the number of pages directly returned by “Hierarchies” to be small, compared to the number returned by “All Pages”.


  • It’s just an way to visually review all the pages I’ve chosen to relate in branching patterns
  • It lets me get into my graph spatially, instead of temporally.
  • I’m a spatial/navigational thinker (not a visual thinker - I don’t need an infinite canvas and stickies!)
  • I like & want Logseq’s default view of information - outlines - but at a higher level of organization (pages in namespaces)


In the example/screencap I shared, I used a hard-coded scheme based on namespaces. That may be distracting. It may make it seem like I only wanted this for namespaces.

Technically, it’s possible hierarchies could be created more flexibly, using queries and page properties, which alex0 figured out (as I describe below).

But for my own inadequate, limited, purely namespace-based example, I ran a query something like this:

And that returned something like this:


But I can’t edit that outline, to add headers, and text blocks to explain what’s down each branch. That would make this a true MOC hub.

More ambitiously, it would be cool to move and rename pages here, and have those structural changes cascade through my graph.

Basically, Logseq won’t let us do to namespaced pages what it lets us do to blocks on pages. (Unless we do it manually).

I just want to keep doing my “Logseq thing”, over this higher level of organization.


  • It’s hard to see it as an anti-pattern when it’s already what gets returned by the {{namespace}} query.
  • Logseq already supports a very rudimentary version of the feature of aggregating and displaying namespaced pages.
  • I’m just providing input about how this existing feature can be enriched and expanded.


  • I think there is huge potential here for Logseq to become very distinct from both Roam and Obsidian.
  • Why not support outlines above the level of the page - editable outlines of namespaced pages?
  • Right now, we can build those manually
  • But the namespace information exists in the database, so it could be automatically generated

  • Alternatively, we could add a “type:: hierarchy” property that takes a path as a value maybe
  • Then a system-provided “Hierarchies” page could show multiple hierarchies.
  • Again, these would be like MOCs, not exhaustive TOCs of the graph
  • “Hierarchies” becomes an MOC hub, not a document root for all pages


  • The hierarchy I explored was only a namespace-based one
  • That’s only because I didn’t have the knowledge on how to do it using queries over properties.
  • The queries + properties solution could be implemented if alex0’s Feature Request here was implemented: Specify and display relations between pages/tags.

  • Namepace-based hierarchies and property-based ones could conceivably all appear in the MOC-hub (the “Hierarchies” page)
  • If the information appearing there was editable (with restrictions), we could add headings into that “Hierarchies” outline to clarify what the different MOCs/hierarchies are


  • tl;dr - I’M just saying that Parent-Child context matters, at a higher level than just on the page.

  • If this higher level of outlining was forced and exhaustive, it would be an anti-pattern

  • Since it’s not, it’s actually just a combination of the main pattern (indented outline) and a secondary pattern (namespaces) that is already supported

  • People would just have to be advised, as Nick Milo does for Obsidian users, that trying to make MOCs exhaustive is a bad idea.

  • MOCs are accelerators, not organizers.

  • It’s wayfinding for people who think about their personal information topically, instead of by today’s date.


  • Different people will differ in the amount of higher-level organization they need to avoid disorientation
  • According to the book “The Science of Managing Our Digital Stuff”, most people far prefer navigational methods to search (for personal information management tasks).
  • Using term-based methods like tagging or search is less preferred for personal info (unlike with public information like web pages)


  • People need navigational structures because then they can rely on recognition instead of recall to access their info, and procedural rather than declarative memory
  • This is especially important if ever Logseq wants to attract a user base that doesn’t necessarily use the tool every single day.
  • Those kinds of users would need recognition-based cues to get reoriented to their graph, and not have to dredge up declarative memories of what might be in there.
  • If the research findings about PIM hold up, the tool that achieves the best balance of navigational structure and distributed graph traversal will have a strong advantage in the marketplace


  • The magic of graph traversal is you can have serendipitous discovery of linkages that grow in value over time
  • But what is the value of doing that from an abstract, search-driven starting point every time?
  • Why not chose a topic-based starting point or launchpad, and then enjoy the graph-traversal magic?
  • Logseq can become the tool that best balances both wayfinding impulses, leveraging the new graph-traversal paradigm, with just-enough-wayfinding-structure for people more familiar with older approaches


  • Roam is doctrinaire and purist about its graph database philosophy, and hostile to hierarchies.
  • I finally became loyal to Logseq because I saw the word “Hierarchies” on a page!!
  • (Also, because key evangelists were badly treated by Roam, I thought)
  • Since it’s there, I figured the Hierarchies functionality would continue to be developed.
  • It would make me sad to learn hierarchies are an anathema to the philosophy and culture of the Logseq developers.
  • That’s why I asked: Would a rich commitment to hierarchies and classification be an anathema to Logseq culture?

Hi @Ramses. I wrote a hopefully simple to understand introduction on why we need a way to organize pages differently than by just namespaces: Knowledge Management for Tags / Tag Hierarchies

This request is not about enforcing “strict” hierarchies in the graph (in the sense of being forced into a folder structure).

It is about organizing a huge graph by adding relationships between pages.
This would enable many additional ways to locate a page, e.g. faceted searches and hierarchical browsing that is used e.g. on Amazon’s website or in a library catalogue.

This request fits very naturally into Logseq’s data model with some small extensions to the search, as suggested in @alex0’s feuture request he mentioned above: Specify and display relations between pages/tags

It would be great to get feedback on these requests, as some of us consider them to be absolutely essential to organize larger graphs. Currently the “best” practice recommended to deal with e.g. Zotero imports is to just delete nodes to simplify the graph. That can’t be the intended use.


@boisjere Can you expand on this? I can’t quite follow what you’re doing here, but I’d like to be able to replicate it.

Well @knowlost - first you have to do the somewhat tedious task of renaming all your files - or at least, all the ones you want to appear in your hierarchy.

You have to put them all in the same namespace, under one top-level name. I used the term “Hierarchies” for this top-level name in one sample I shared. I used the term “All Namespaces” in another. If you like the idea of Maps Of Content, you could write “MOC-Hub” as your top-level term, or “TOC” for Table of Contents, or “Index”, etc.

Then you have to go through and rename all the pages in your graph to put them under that top level name. Right now I’m working on some stuff about fiction writing. So I have ideas like Plot, Theme, Character, Arcs, and types of Arcs, for example.

I’d have to rename the pages like this (using MOC as my top-level name):


It’s ugly. Every page ends up having a fully specified path as its page name. Pages are named according to their breadcrumb trail in the hierarchy you want to build. It won’t scale very far.

Anyhow, doing all that will give you an MOC page. Navigate to that page. There, you just type the following query on a line: {{namespace [[MOC]]}}. It seems like a self-referential query, because you are asking it to return all the pages beneath and including it, but then displaying it “on itself”. In truth, I think the query just returns what it returns, and doesn’t care where it’s called from.

That will give you a tree of all the pages in the MOC namespace. Then you add that page to your favourites, and you have essentially the kind of functionality I’ve been squealing about all over this forum.

You could segment your graph into several namespace-based MOCs. So you could create an MOCs page, but not use it in any namespaces.

Then you could use those God-awful breadcrumb-style page names, using several root-level names. So I could do:




Then on my MOC page, I could put two queries:

{{namespace [[History]]}}

…and on a separate line…

{{namespace [[Story-Theory]]}}

Then I could add the MOCs page to my Favourites like before, and there’d be a few MOCs on it

Nick Milo often says MOCs should not aspire to become exhaustive Tables of Contents. They’re just accelerators to get you into good spots in your graph. So you wouldn’t need to have breadcrumb-style page naming everywhere, just on pages you wanted to index this way.

The advantage of using a namespace-based approach is that the branch in your tree leading up to a page appears in the “Hierarchies” section at the bottom of each page.

However, a page can’t be in two namespaces at once. So my approach doesn’t allow for polyhierarchies, something @gax has written about extensively on this forum.

If we used the properties-based approach @alex0 devised, we could have polyhierarchies, but queries would have to recursively return “parent-of” and “child-of” pages based on those properties. I don’t think that’s on the Logseq development roadmap.

You can also just create an MOCs page, and hand-code the hierarchy, by making a normal outline, then putting only or mostly page names on it - but it won’t auto-update, not will it appear in the nice, salient “Hierarchies” section like the namespace approach enables.

Anyhow, the approach using the {{namespace [[ x ]]}} query is simple to execute in theory. Renaming pages by hand is a pain though.

1 Like

I’m really enjoying this discussion, even though I barely understand it lol.

Organisation, in Logseq, is what I’m struggling with, as I’ll detail in my next post here on the Learning Sprint.

I particularly like this idea of Logseq differentiating itself from others:

I guess this is the challenge for any 2nd Brain PKM software. Loving this software and am excited about possible future developments:

@boisjere @gax

I just noticed I can move .md files (using a file manager) everywhere in the graph folder (in the root of the graph, in a custom subfolder or a subfolder of /pages) and Logseq just recognize them as they were in /pages. You just need to make sure there aren’t file with the same name in different folders.