Would a rich commitment to hierarchies and classification be an anathema to Logseq culture?

First of all, I’d like to thank the adventurous team at Logseq for committing to the endless and sometimes thankless work of building a new software platform from scratch. I really appreciate what this tool is, and am excited for what it may yet become.

I’d also like to thank the company and key influencers in the Logseq community for not being entirely hostile to the idea of hierarchy in information organization. For many of us, hierarchy is a natural way to construct access paths into our graph.

I appreciate hierarchy as a way of clarifying thought. I don’t mind if it breaks down or goes stale from time to time. Cleaning it up, when I feel the need to, restores clarity in an important way.

I especially don’t mind if hierarchy is partial, in connected-thought environments like Logseq. I view hierarchies as lists of saved queries that provide me with a clean way into my graph. I appreciate them as a tool, alongside chronology (Journals), favourites, search, query, hyperlink traversal, graph examination, scanning the linked and unlinked references, and looking at tag clusters.

Hierarchies are filters over some of the graph that help me get close to 100% signal and 0% noise, at the cost of excluding interesting adjacent ideas. However, with a bunch of other access pathways in the mix, you can use hierarchy to find your starting point for a work session, then shift to other strategies of traversal. The Journals page is used the same way in many people’s workflows.

I wonder if other people in the community feel the same way about the value of hierarchy as one way into the graph?

If so, that would support the case for Logseq, and the culture surrounding Logseq, to differentiate itself from other tools in this space by validating hierarchy as a useful tool and an area for ongoing development. Not necessarily enforced, exhaustive hierarchy like a foldering system, but something between that and Nick Milo’s MOC concept. The distinction with MOCs would be in the level of core software support for hierarchy construction.

I personally would like to see a Hierarchies link in the left sidebar, right under the “Graph View” link. I created a sanitized little Hierarchies mockup. In this mockup, all namespaces start with the Hierarchies page reference. Then I used the self-referential embedding trick to grab all the child page links, and favourited the Hierarchies page so it lives in the sidebar.

This opens to show the following page:

If this looks suspiciously like a foldering system, it’s in part because it’s not an editable outline like any other Logseq page. If this was more like a typical page, and you could add bullets/content to it at each level, it would become more like an auto-generated master Map of Content for any pages pulled into namespace schemes. If you could add links to other related pages at will, it would be even more like an MOC hub, rather than a foldering system.

There are some interesting constraints on such a hierarchy page, including preserving outline level relationships more deeply into the graph, rather than just on the page. Cascading outline numbers down though the graph is also incredibly tedious right now - but that’s part of a whole other conversation on applying classifications over parts of your graph. I won’t poke that bear right now.

There are other conversations in this forum related to my hierarchies idea. There are feature requests for different ways of presenting hierarchies, showing breadcrumb trails in different ways, smoothing out how headers are opened or collapsed, or displaying a TOC tree for the current page in a sidebar, where twirling arrows down never opens up bullets that aren’t marked as headers, for cleaner structured access to parts of long pages.

It seems to me that there’s a single hierarchy-like function here that unifies these feature requests at some level of abstraction.

I could have made this topic into a feature request, but I wanted a more fullsome idea of what other people think first. Perhaps all this can be achieved with a plugin or something similar I have yet to discover.

  • Is hierarchy a valuable enough filtered view over part of the graph that it merits deep and careful development over a long period of time?
  • Is acceptance of hierarchy as an approach to knowledge organization a potential point of distinction from both the software and cultures surround similar TfT platforms (where hostility to hierarchy is widespread)?
  • Do you like and use hierarchies to keep your thoughts organized?
  • Would you like a system-generated-yet-editable Hierarchies view (of pages you’ve organized using namespaces) in the left panel?
  • I am missing absurdly obvious things in Logseq that allow me to achieve everything I want without needing to request a new feature?

After a long period of living in 'tool-choice hell", I am finding my home here with this tool, but I’m still really very new with it, so I don’t want to throw requests at the Logseq developers blindly.

1 Like

Well I’m not sure about them potentially being “contrary to the culture” but I agree with you 100% that hierarchies and classification schemes are essential elements of an effective “knowledge repository”.

I personally consider hierarchies to be extremely important, if an item can appear in multiple parts of the tree. If a system would force a unique hierarchical classification of each item, and the item would only be visible at a leaf node, it would not be beneficial.

What I would like to see (some of this already works with nested tags):

  • Tags get a place in the hierarchy, e.g. “Historical Complexes” will be marked as part of “Non-Fiction”, “Non-Fiction” will be a part of “Writing Projects”
  • The relationship for tags and hierarchy positions has to be 1:n, i.e. each tag can have multiple parents or none. E.g. “Historical Complexes” can also have a 2nd parent “History”, which is a child of “General Interest”
  • Entry of tags should have some form of smart autocomplete, i.e. when I enter “History”, it suggests “Historical Complexes”
  • All items also appear under their parent categories, so when I click on “Writing Projects”, it will link to all pages under this category. The reason for this is that one should not have to go to a folder at the bottom of a hierarchy to find an item

As a generalization of the tag system, Logseq could implement nested searches. This would allow to place all pages (or blocks) that match a certain search into a folder hierarchy (e.g. “Historical Complexes” in the “Non-Fiction” search folder, which could also contain other subfolders. This would be an improved version of Zotero’s search folders, which don’t allow hierarchies. Such an approach is more powerful (e.g. one can have search folders that require multiple tags #history AND #fiction), but also slower.

1 Like

The relationship for tags and hierarchy positions has to be 1:n, i.e. each tag can have multiple parents or none. E.g. “Historical Complexes” can also have a 2nd parent “History”, which is a child of “General Interest”

So I think you’re saying that Logseq should support polyhierarchies. That is when a child can have more than one parent.

So on a website, you could find an iPhone by clicking on “Electronics”, “Smartphones”, “iPhone”, to get to a target page, like “iPhone 7 Refurbished”. But up at the top level of the hierarchy with “Electronics” there could also be “Apple” and you could go from “Apple” to “iPhones” and get to the same target “iPhone 7 Refurbished” page by that route.

“Electronics” would be in a “by Department” facet array, and “Apple” would be in a “by Brand” facet array in this example.

All items also appear under their parent categories, so when I click on “Writing Projects”, it will link to all pages under this category. The reason for this is that one should not have to go to a folder at the bottom of a hierarchy to find an item

I’d like that too. That’s why I suggested a system-generated hierarchies page nonetheless be (almost) like an ordinary page, so you can be looking at parents and children to multiple levels of depth in one view. Is that what you mean? Maybe I’m not following you properly - or maybe I haven’t played with nested tags enough in Logseq. I did in Obsidian more.

As a generalization of the tag system, Logseq could implement nested searches.

Some of what you say makes me think again of the idea that a hierarchy is really a type of query that gives you a filtered view of a subset of your graph.

The underlying knowledge object is a graph with no top or bottom, but the nodes are constructed throughout outlining and indenting, which are mini hierarchies. It’s like the molecular/local structure is hierarchical even though the molar/overall structure isn’t.

Over time, the knowledge graph we use to store all our thoughts in loses any molar/overall hierarchical shape, but humans still use hierarchy and categorization to organize their thoughts at times. So picking a hierarchy as a lens for viewing as much of the graph as falls into its scope is a valuable view to offer.

An example of a software that implements this beautifully is Trilium. It has many of the benefits offered by logseq. A disadvantage, and reason I started to look for another solution, is that it stores all information in a sqlite database instead of individual files.

Yes, that is exactly what I was thinking about. Also, tags don’t need to be part of a hierarchy, so it doesn’t interfere with the current use of tags. On the other hand, a strictly hierarchical taxonomy, like e.g. the Dewey Decimal Classification would be a disaster, as many items could sit in many places of the tree.

There is also the W3C SKOS Simple Knowledge Organization System with a primer. This goes a bit beyond what we need here and also has a huge amount of metadata, such as notes about the individual categories, but the basic concept is to have skos:broader, skos:narrower, and skos:related to define relationships between categories.
These are not transitive:
There are also transitive versions skos:broaderTransitive, skos:narrowerTransitive:
There are also ways to specify categories for faceted searches.

I don’t know if SKOS is the state of the art and how this compares to OWL, but this is the general concept of what I would like to see implemented: a way to specify relations between tags to automatically build efficient searches.

I agree. Given a relationship between tags, many types of data presentations can sit on top of this, at the page level, block level, items expanded, not expanded etc. For example, in your “Hierarchies” view, there could be a button to fully expand the content, just show the first blocks etc. a faceted search could be placed in the sidebar.

I was thinking about hierarchical queries that can be used to build different hierarchical searches beyond tags. Currently, each query searches one level:

{:title [:h2 “Your query title”]
:query [:find (pull ?b [*])
:where …]
:inputs […]
:view (fn [query-result] [:div …]) ;; or :keyword from config.edn
:result-transform (fn [query-result] …) ;; or :keyword from config.edn
:collapsed? true
:rules […]}

So for example, to find a programming tag

{:title “All pages have a programming tag”
:query [:find ?name
:in $ ?tag
[?t :block/name ?tag]
[?p :block/tags ?t]
[?p :block/name ?name]]
:inputs [“programming”]
:view (fn [result]
(for [page result]
[:a {:href (str “#/page/” page)} (clojure.string/capitalize page)])])}

If queries could be nested, then Logseq could automatically generate a hierarchy from the query. Each query would need a unique identifier and a list of identifiers of child queries:

{:title [:h2 “Your query title”]
:identifier “identifier of query”
:children […]
:query [:find (pull ?b [*])
:where …]
:inputs […]
:view (fn [query-result] [:div …]) ;; or :keyword from config.edn
:result-transform (fn [query-result] …) ;; or :keyword from config.edn
:collapsed? true
:rules […]}

When this query is run, it would present the search results in a hierarchical fashion. Of course, if one is not careful, this can lead to very complicated queries that might never terminate and it is far more complex than specifying relationships between tags. On the other hand, it would allow to build all kinds of interesting hierarchies beyond just tags, e.g. a hierarchy of all todo items which can then be refined by properties, or a list of all pages that have a pdf attached that can then be refined by tags.

I am not saying this should be the default way to generate hierarchies, relationships between tags is the way to start.

1 Like