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

[alex0]

I get what you are trying to accomplish here, but why properties to store relations like in my example above wouldn’t be enough?

My point is that we already have the data structure in Logseq and we just need a better way to query it.

If you where able to type something like {{tree }}, for example {{tree extended-by}}, and it renders an indented list of pages linked together by the specified property (in this case “extended-by”) would it be enough for you?

For example:

Page A
...

Page B
extended-by:: [[Page A]]

{{tree extended-by}}

renders:

* Page A
    * Page B

[alex0]

@boisjere

In terms of UX, I wish I could edit “All pages”, “Linked references” and “Unlinked references” exactly like a standard page, in outline form, with maybe a drop-down menu specifying the query:

If you mean that references etc should be a special default case of what we are discussing here and should be displayed with a command, i.e.

{{linked-referencies}}
{{unlinked-referencies}}
{{namespaces}}
{{tagged-pages}}
{{tree <property>}}

then I’m totally with you.

[boisjere]

You know @gax, I think your feature request is really powerful. I would really, really, really want software that can do this with seamless UX. I am currently hacking together some of this kind of knowledge organization using these tools:

• Vocbench (http://vocbench.uniroma2.it/)
• TemaTres (Tematres: management formal representations of knowledge)
• Taguette (https://www.taguette.org/)

I’m using Vocbench and TemaTres to try and connect with existing taxonomies, and Taguette to infer my own, over my collections of notes. I am doing it for tag control.

This is exactly the point you make in your Feature Request draft. It fights tag explosion, which matters for those of us who like to maintain a synoptic overview of what our knowledgebase contains. It also surfaces knowledge, because some categorical knowledge can be inferred directly from taxonomic or categorical relations.

I don’t have anything to add really.

• You are doing a very good what and why feature request for this kind of tagging
• @alex0 is very good at explaining best ways how to do it in Logseq
• I just want to start using it.

I think that with you two doing much better work than me, my feature requests can be residual UX considerations - that queries leveraging SKOS or hand-coded trees be returned as editable outlines that can be saved as auto-updating pages. Something like that.

The best I can do is suggest how I want the thing to feel in my hands.

[boisjere]

This is tantalizing! And I guess an SKOS importer would be able to map SKOS info to this Logseq data structure?

If that is the case, your ideas about how Logseq can already handle this data extends the feature request being constructed by @gax. If there was a section in that feature request which said in more detail how Logseq is already able to handle this data, then that focuses the question.

I think the question becomes - should Logseq’s core behaviours evolve in a way that more deeply support the management of these properties, or are we left with a personal burden of constructing queries, or waiting for a plugin and hoping its development always remains up to date.

Maybe this is ultimately not a technical question, but a user question. If people - and scholarly communities - who deal with taxonomies and classification schemes frequently (academics to a degree, transnational organizations to a very significant degree), are to be supported by Logseq, it would be best to make taxonomy-management functions core.

[alex0]

And queries should definitely have more display options and not only block list and table.

For example a carousel of cards:

[gax]

@alex0

I get what you are trying to accomplish here, but why properties to store relations like in my example above wouldn’t be enough?

My point is that we already have the data structure in Logseq and we just need a better way to query it.

If you where able to type something like {{tree }}, for example {{tree extended-by}}, and it renders an indented list of pages linked together by the specified property (in this case “extended-by”) would it be enough for you?

@alex0 What I would like to do is decouple the tagging of pages from the organization of the tags themselves.

So for example, I might tag many pages with parent, child, and teddy. Over time, as the number of tags explodes, I find that I need to organize my tags, so I create a hierarchy and tell Logseq that teddy is a child node of child which is a child node of parent. I also tell Logseq that teddy is a child node of stuffedAnimal, which is a child node of toy. This automatically makes every single page tagged teddy appear in the hierarchies, without needing to edit the individual pages.

Another use case: Items imported from other systems (e.g. Zotero) have many overlapping tags, such as “History, 20th Century”, “history”, “History / World”. In practice, this creates graphs that look like this

and is practically unusable, the recommended solution being to just delete the tags (and discard the information contained in the tags).

A much better solution would be to create your own hierarchy, and then tell Logseq where the existing tags fit into your hierarchy. For example, I could search for all tags containing “history”, and place them under my history hierarchy.
This will automatically categorize all of the imported data without needing to edit any of the pages. Later, as my organizational system changes, I can move the tags around or create other hierarchies that fit my workflow.

[alex0]

Yes, I got the use case, but what you are asking for is assigning some properties to tags so that they form a hierarchy i.e. one tag has some other tags as child. And someone mentioned “polyhierarchies” or something like that because some tags may belong to different hierarchies.

I’m saying this is already possible since tags are pages and pages can have properties with the syntax:

property-name:: something, [[Page A]], URL, whatever

So you can already structure those polyhierarchies but you don’t have the UI/UX to query and display them in an efficient manner.

I.e. you can use {{query }} syntax to list pages that have certain properties but it’s not iterative, you can’t make it display

* Page A
   * Page B
        * Page C
   * Page D

when these pages are linked together by a property you define, for example “extends”, “extended-by”, “generalizes” or whatever name you want to give to each of the polyhierarchies you need.

If you don’t want to display an indented list but a graph it doesn’t matter, it’s still an UI/UX issue; no need (from what I can tell) to extends Logseq data structures.

Is it clear what I mean?

[gax]

SKOS items can have notes, which can contain images.

[gax]

@alex0

I’m saying this is already possible since tags are pages and pages can have properties with the syntax:

property-name:: something, [[Page A]], URL, whatever

So you can already structure those polyhierarchies but you don’t have the UI/UX to query and display them in an efficient manner.

@alex0 I get it, I didn’t think about tags as pages. User interface would then pull all the relationships out of the individual pages and make them editable.

[boisjere]

This is so cool @alex0 ! If it’s already possible to specify the properties we need, we’d benefit from a standard way of doing it, so we can enjoy all the benefits of the large feature request @gax was drafting. Also, an SKOS-properties standard in Logseq would be a draw for many people.

And of course, people not interested in this could ignore the whole thing.

[gax]

I’ve created a feature request: Knowledge Management for Tags / Tag Hierarchies

[boisjere]

Hey @pvb, I just checked out Trillium and I agree!

• a) it beautifully handles a tree-based organization with the ability to access clones of a note of on different branches in the tree
• b) it sucks that it’s implemented in sqlite. Logseq achieves a better separation of data from behaviour.

Also, even though I’ve been pushing hard for a more hierarchical way to traverse my graph, Trillium seems a bit too rigidly hierarchical. What I really want is a flexible graph, with lots of ways to traverse it - including a tree-constrained manner of doing it for content that is naturally connected that way.

I only want to put info into tree format that is helpfully organized that way. I don’t want to be prevented from doing that, but I don’t want to be forced to do it either.

[boisjere]

@gax I see there is talk about simplifying the feature request.

It’s funny because here I see a feature request being tweeted out that your ideas would support. It’s exemplified without explanation.

I guess it’s better to post more full ideas in the general discussions area, and very simple concrete things in Feature Requests

[gax]

This is a great idea and fairly straightforward. I am not sure how much text is required to calculate a meaningful similarity metric. It would work really well for scientific documents, though.

I am not very familiar with this, but I have seen some work on automatic concept hierarchy generation.
It might be possible, given a large enough collection, to automatically create yet another type of hierarchy at the tag level.

Length is a tradeoff, if I shorten it, some people might say “but why can’t you use tags?” Not everyone might be familiar with the concepts. The important part is at the top anyway. Let’s see if it generates any feedback.

Do you want to add some user interface ideas to the proposal? You probably saw this, but the SKONS notes support arbitrary documents and also images, so one can build e.g. a tree with little thumbnails.
It could also just take the first image it finds for any tag. Lot’s of opportunities, I really hope this can become part of Logseq.

[boisjere]

I’ll add some feature requests over time, based on this conversation. I’ve fallen behind on other things and will have to do that later. I’m also going to play with queries and properties a bit first to see if I can get some ideas working.

[gax]

@alex0

I don’t see why you think this would be more computationally intensive than the rest.

It’s just like queries but iterative to “follow” a property.

I think we’ve been talking past each other. I agree with @alex0’s suggestion for adding tree and graph searches and for storing the information.
I did not think about designing hierarchies efficiently, which @boisjere’s program can do.
For now, I’d be happy to even design the hierarchy by hand in Markdown.

I was solely talking about efficiently classifying existing nodes. While theoretically this can be done on each individual page, it is too cumbersome to classify hundreds or many thousands of nodes this way.

What I would like to see is this:

The process should be designed to be as efficient as possible, such that it is realistic to sort a few thousand yet unclassified tags into the hierarchy.

[alex0]

If I understand it correctly you want to be able to select multiple pages (from the graph or from a list) and assign/remove the same properties at the same time. This could be useful in general and another feature request.

Also, the advantage of using text files to store data is that you can write scripts or entire programs to generate or manipulate them programmatically so you could manage properties/tags with another tool.

[gax]

@alex0

If I understand it correctly you want to be able to select multiple pages (from the graph or from a list) and assign/remove the same properties at the same time. This could be useful in general and another feature request.

Exactly. I don’t worry about the taxonomy generation, there are a couple tools available and in the worst case in can be done in a text editor. In contrast to the number of tags, this is a small number.

What I would like to see is:

• a way to efficiently add properties. I think it makes sense to have this in Logseq UI to leverage the existing search functionality on the graph. It should have a (poly) hierarchical representation of the nodes on the left, so that we don’t just move items between random tag clouds. It would be easy to parse the properties from the pages, but at the moment I can’t think about a more efficient way than something similar to the UI I suggested. I am open for suggestions.
• tree search, as suggested by you. This also needs to be a core part of Logseq.

[boisjere]

I’m getting indications that it is a bit contrary to the culture. The coolest feature about Roam and Logseq is bidirectionally linked block-based graph traversal. Early evangelists are super-excited about this, and kind of dump on earlier (millennia old) ways of organizing knowledge.

I get it as a way of highlighting what’s new, but I think the baby’s going out with the bathwater.

The main evangelist who is trying to balance both the old and the new ways of managing information is Nick Milo. He loves minimal foldering, Maps of Content, and Datascopes, as ways of maintaining enough high-level knowledge about your content to enter the graph with some positional awareness.

For those of us who need that initial moment of orientation, doing pure block-based graph traveral sucks, quite frankly.

Early evangelists are full of excitement about the moment they “got it”, and they’re trying to help everyone else “get it”, but aren’t widening the funnel much for those of us who prefer to do things a bit differently.

Historically, this has been very associated with the culture around Roam, but it happens a bit around Logseq too.

I’m the kind of person who is very mentally clear at the 50,000 ft overview level of my information, and I need to orient myself to my knowledge landscape before I decide where to land and hunt. But early evangelists of block-based PKM tools are sometimes most excited about ruling that out.

I want the new ways of exploring information, but I want to choose my starting place, somewhere besides the Daily Journal, or an un-indented list of Favourites.

So my question remains genuine. I’m not sure if a rich commitment to hierarchies and classification is kosher, for Logseq’s developers.

• Is it an exciting way to differentiate themselves from Roam and support a wider market of users?
• Or is it an irritating distraction and people like me should go and struggle with Obsidian
• Obsidian isn’t outline-based, but which has a culture supporting soft hierarchies of knowledge

I decided to stop looking for tools, and chose Logseq, because of that “Hierarchies” section on a page. It felt like I was “coming home” to a tool that combined the ancient magic of classification with the new magic of graph traversal.

But I fear that the “Hierarchies” feature will be considered to be an aberration that they will leave to wither and then phase out - ironically because people may use it too much, the wrong way.

Not everyone will have that “conversion experience” to pure block-based graph traversal, and they’ll choose to focus on the true believers, and not the larger masses.

I anticipated this kind of issue. I wanted to know I could discuss hierarchies and classification with some clarity and energy. I didn’t want to disrupt this community, if in fact I was wrong about what Logseq plans to become.

So I’m still unsure if this is the place for me. It’s a bit sad, because I don’t want to be in “tool-choosing hell” again… but I don’t feel good when my needs are deligitimized (Different ways to structure data - #27 by boisjere) - especially because I love this tool, and I think my needs reflect those of future users, farther along the technology adoption curve, “across the chasm”.

[alex0]

If I had to design this from scratch:

• every folder in our file system would potentially be a “graph”, even nested in each others
• the info about a certain graph would be saved in an hidden .logseq folder in every folder that is a graph
• it would be possible to open every Markdown file with Logseq and when doing so it creates a graph starting from that folder (creating the .logseq one)
• mentioning pages between different graph could be possible using relative links (../ syntax to go up)
• journal would be a plugin to manage one or more specified folders/graphs (even hidden ones inside the ones above)
• Logseq wouldn’t be set to “one graph” for each instance, instead it would manage graphs like file managers do with folders

For example:

📂 All Encompassing Graph
  📂 Subgraph 1
    📂 .logseq
    📂 Journal
    📄 Page.md
    ...
  📂 Subgraph 2
    📂 .logseq
    📂 .journal
    📄 Page.md
    ...

and hide relative paths from non-editing mode in Logseq i.e.

[[./journal/2022-07-22.md]]

is displayed as

22 July 2022