Different ways to structure data

[boisjere]

I’m also an “everything out” organizer. In a kitchen, I need either open shelves or cabinets with glass doors, in order to maintain order. I need see-through storage containers. I constantly need to see my organizational structure at a glance, in order to know where anything is, except for things I use constantly. I’m fine with messiness. I’m a messy-desk person. It just needs to be the kind of mess I can stand back and get the overview of. I rely on spatial overview first to get oriented to an information space, then after that, I can start sorting backwards in time.

Like in my email, sure I let things pile up temporally and scroll back through time to see & recall stuff, but I have (I’m almost embarassed to say) 23 email accounts, all entering my email client. Each account is one I give out for slightly different purposes, in different topical communities, and so in addition to searching back in time, I can check the inbox of any one account and get that slice of my world filtered for free.

So getting an overview of all my different reverse-chronological email streams in my unified inbox is crucial, as is my ability to select just one branch. A space-like, category-like organization needs to be primary, and then I can deal with time-based organization after that.

One response to this preference would be for the Logseq developers simply to assert that time-based sequences of logs is the primary navigational interface for Logseq (as per the name), and if I want a system that offers hierarchy of any sort as a primary navigational interface, I should look elsewhere.

That’s fine, I guess. I will look elsewhere in that case. But I invested time and effort in Logseq over its alternatives precisely because of the “Hierarchies” section I saw on Logseq pages. I assumed that was a signal the concept would be considered important by the developers.

Also, empirical studies of PKM practices, as far as I am aware, support precisely the pattern of “some foldering, plus search and sort by time/histories”. People tend to use a few big buckets to get oriented to clumps of related information, but then check out filenames and recency of files and so on to find what they need.

So all of the many suggestions in this thread to provide better UIs for non-exhaustive, overlapping hierarchies is a very good fit for the kind of “sloppy but important” foldering that has been observed among users of classic desktop computers.

[Leslie_P]

I’m an “all of the above” depending on the day kind of person. Search, chronological, tags, folders - I need to be able to use all of those tools to access the data that I spent time putting in my PKM.

I really hate that so many of the PKM apps want us to abandon one or the other of these tools in favor of forcing our brains to do something completely new. Stop it. Quit trying to change me. Start trying to help me.

Logseq is an outliner, CLEARLY there is an appreciation for the hierarchical nature of thought and organization.

Zotero is familiar to many folks here - every item can be in multiple collections, can have tags, has metadata fields, and is searchable. The hierarchical collections are easy to view and navigate, all the tags can be seen, clicked, and edited. It’s easy to figure out and use, and I don’t feel like my content is lost.

But I also want a chronological journal, and outline format, and backlinks, and I suppose a graph (though I don’t use it). Like I said…I want it all.

Take the Zotero concepts and add them to the outliner with backlinks and pretty graph and we’re totally in business.

[sagitman]

This is an incredibly helpful and succinct summary of why am I am struggling to use Logseq despite my best efforts to get comfortable with it - the lack of organization within Logseq’s structure for pages, etc.

To me, having to use recall instead of recognition to access my information is a huge obstacle to my enjoyment of using the application. While back-linking is great and I make liberal use of it whenever I am creating a note, sometimes I create a note with no back-links either because (a) it might relate to a topic that is novel to me and I don’t yet know what the note’s relationship to other notes will be or (b) there might be novel relationships that will only surface with time. Either way, this inherent ambiguity is a source of anxiety when working with Logseq because it feels that I have to constantly remember everything that I’ve put into to my graph because otherwise things will get lost in the morass of “All Notes”.

On a separate but related note, Logseq’s current implementation of aliases is pretty terrible and only adds to the above-mentioned anxiety of using the application as it forces me to have to remember which among several aliases is the actual page that all other aliases are supposed to point to because the application offers no help at all with regards to that.

There are definitely things I like about Logseq and look forward to its further development. But as it stands, I just don’t feel comfortable using the application in its current iteration. I appreciate that it want to have a very specific point of view, and in many ways that point of view suits me (e.g. outlines, back-links, clean UI, search, tags, etc.), but in other ways, it feels like Logseq wants my brain to think in a fundamentally different way than what is natural to me. For me, having some measure of hierarchy through chronology, inbox and (limited use of) folders would go a very long way to making the app more use-able and, I imagine for a lot of potential users out there, user friendly by offering recognition of data as an alternative to recall.

[alex0]

I understand that Logseq could provide better UI/UX for this, but why don’t you just

• Organize Markdown files in folders like we do with our documents anyway, or
• Maintain some indexes of pages and eventually one with yet to be organized notes?

In the latter case you could add “Organized” as page-tag and in the page [[Not organized]] put a query that lists all the pages without the tag Organized.

Logseq provides powerful generic tools that the user can combine in creative ways and this leads to complains like the ones in this thread, but if Logseq forced one specific workflow there would be even more complains because a workflow will fit only a small portion of the users. And indeed Logseq receives complains in the areas where it forces specific workflows, like the task management one with TODO/DONE etc.

[alex0]

Also I am convinced that one shouldn’t create pages lightly: Logseq has this great feature of focusing the view on a block and its children. This let you write notes as “root” blocks, the to shortcut let you collapse all blocks so that you have an overview of your notes and then you can click to a bullet point to focus on one of them.

---

Edit, example page to gather notes before and after clicking a bullet point:

---

[Joe_Smoe]

What you described is literally 100% of what I suffer from when using Logseq. This lack of a fixed structural system to represent my graph has been driving me mad for the past 2 years when I started using Logseq. The tool really just brings too many benefits for me to give up on it just yet. However, the need to recall where I stored something in my notes really defeats the entire purpose of a second brain; as Tiago states in his book:

“Now, it’s time to acknowledge that we can’t “use our head” to store everything we need to know, and outsource the job of remembering to technology.”

This state of remembering should also include a hierarchy structure of our pages.

[markmcelroy]

I’m a pedestrian user of Logseq at best. What I’m finding, though, is this:

At first, “tag it, link it, and give it properties” works reasonably well, especially when the number of notes remains small. For me, though, this approach isn’t scaling well … and I find myself needing some kind of structure to help me a) navigate my notes and b) make sure I’m using tags, links, and properties consistently.

This creates an administrative burden – the manual maintenance of a map – that feels more like work than play. And the effort needed to maintain that map will only increase over time.

This is already a challenge for me, even in my own (very simple) applications of Logseq over two months. Search results are fine, but they don’t dispel a growing feeling that I’m getting lost in a trap of my own making.

[alex0]

I’ve found another way to organize pages that is handly to browse like namespaces but more flexible.

It’s “tags::” property, it is a special property for pages because it will make some pages display the “Pages tagged with <current-page” section.

It can be used with this structure:

Child.md
tags:: [[Parent]]

Then at the bottom of [[Parent]] there will be the section mentioned above with the link to [[Child]].

---

My example in the first post would be implemented like this:

Linear Algebra.md
tags:: [[Algebra]]

Algebra.md
tags:: [[Mathematics]]

---

This is basically like organizing pages in folders but more flexible because a page can be in different “folders” at the same time.

[alex0]

There is another way to organize pages and it is my favourite so far because it scales well with very long complex “poly-hierarchies”:

You can write indexes like the following where you want:

- [[Index]]
  - [[Foo parent]]
    - [[ Foo child]]
  - [[Bar parent]]
    - [[Bar child]]

Then when you are on a page and you want to see where it is in one or more indexes, use

{{query (and <%current page%> [[Index]])}}

You will be able to browse the hierarchy without leaving the page.

You can create a macro with it and a custom command, so that you can just type /Index at the top of a page to add it.

---

P.S. you can use my minimal style for queries to make the indexes look more native:

Minimal style for some queries

This hack will result in this style for queries tagged with #minimal-query: [image] Query structure: Minimal style for some queries #minimal-query #+BEGIN_QUERY {:query (and [[your query]] [[here]] ) :breadcrumb-show? false :result-transform (fn [r] r)} #+END_QUERY CSS to put into custom.css: [data-refs-self*="minimal-query"] .custom-query > .flex > .content { display: none; } [data-refs-self*="minimal-query"] .custom-query .fade-link { display: none; } [data-refs-self*=…

[Joe_Smoe]

@markmcelroy

This creates an administrative burden – the manual maintenance of a map – that feels more like work than play. And the effort needed to maintain that map will only increase over time.

Precisely. I honesty think they need to implement a file-browser that we can use to create folders and nest pages inside of. Then when we insert a page reference into our notes, display a hint just above the page-reference name that shows the path of where the file is located at in the folder structure. If more than two pages with the same name exist, display them both as separate items but display their folder paths above their names.

Example:
Say I am taking notes on [[Data Structures]] for Knowledge Management. I have two pages in my graph for [[Data Structures]], one for Programming and one for Knowledge Management. When I want to capture a new note on Data Structures for Knowledge Management, I start the linking process [[Data Structures]] and Logseq presents me with two options: the first that is under Knowledge Management, and the second that is under Programming. I can now wrap all my Knowledge Management notes for Data Structures using that first page, while keeping my Data Structure notes for Programming seperate. Thus I now end up with structure to help me organize.

With this complete, I would then render the tree structure on the page so you can expand open a folder and view other related pages that are nested inside, or traverse up/down the tree as needed.

There really is no need to reinvent the wheel here and design something brand new. Just give us the ability to structure our notes in a way we are all familiar with and leave it there as optional so folks can choose to use it if they wish.

Final note: I would leave tags as a global feature. Meaning that tags have no hierarchy to them. This could then provide some more benefits to the tagging system and allow it to be used for grouping related content together. Tags should also not create an actual page-reference or physical file on the filesystem. They should only act as link nodes that can link notes together, but they do not actually exist on their own except in the context of its capabilities to group content.

[alex0]

What indexes I mentioned above look like:

[eightbt]

While tagging and namespacing certainly works, it feels like a lot of friction. I’m finding it tedious to just type in “MGMT-364” over and over just to file my school notes, and keep them separate from similarly named “Week 3 Lecture” notes for other classes. Like, I can’t state how often I accidentally created a “MGMT264” page because I can’t type to save my life.

I guess I could change the way I do notes. Jam it all into a journal page first, then extract it to a well named page. But that also is friction – learning a new way to work. I’m not looking to become a gardener. I just want a way to jot down info I don’t want to forget, and quickly find it when I need to. Remembering that I learned “something about less rigid product development flow” as part of “some class last spring” is more likely than me remembering that there is this think called “Agile Methodology”, or that I learned it on February 22nd. Flipping through a dozen lecture notes pages is good enough search capability for me in this case.

I think having an alternate view to manage namespaces would cut down on friction by a lot. Like many have suggested, a folder view is natural. It matches how namespaces work in reality (one location in a tree). Being able to see the whole tree at once and move items around would make it easier to groom the kb. Creating a note “inside” a node of the tree would automatically start the page name with the namespace filled out – a boon to poor typists such as myself. Behind the view, the data would still look and get updated in the same way it does today so peoples’ queries would still work.

Accommodating items in multiple locations would be more challenging. Trillium Note let’s you have a page in multiple locations of the tree, but I find it undesirable to do so in practice. When trying to link to the note, you see all of the locations in the auto-suggestion box – messy. Personally I don’t derrive much value from doing so – navigating a graph view would be more than enough if I ever wanted to see all the varied linkages.

[alex0]

Namespaces are not folders not they are meant to organize existing pages into hierarchies. Namespaces in Logseq are what namespaces are in general: a way to disambiguate different things that happens to have the same name.

Have you read about the indexes I mentioned above? Logseq already has this awesome UI for organizing blocks hiearchically that we usually call the outliner, so why not just use that?

In my workflow when I want to organize some pages in a hierachy I just write it as indented list of blocks where each block has a page reference. I tag the top of the list with #index or class:: [[index]].

Then since I have defined a custom command I just need to type /Index somewhere in a page to output a {{index}} macro I defined as a query with a simple AND between current page and [[index]].

The result is that I get in which indexes the current page is mentioned:

[eightbt]

Hmm, unless I’m missing something, folder are namespaces? You must have unique filenames in a folder, but can have different folders with the same filenames across them. IMO, the term folder is a throwback to the days when developers had to make information systems more relatable to office workers.

I did see your example of using index pages, and I do something similar already:

In my use case I don’t have very unique names for my notes because it’s essentially “week # lecture notes” for every class I take. Right now namespaces don’t give me any functional benefit. I might as well name my lecture notes like [[week 5 lecture #mgmt-364]].

Actually …. I have an idea…

[alex0]

@eightbt

Hmm, unless I’m missing something, folder are namespaces? You must have unique filenames in a folder

Yes but folders being namespaces for files is secondary: we don’t use folders to disambiguate files with the same name, we use them to organize files with a hierarchy that has some kind of logic.

Let’s say you have [[Alice]], a page for a specific person. You want to put [[Alice]] both in [[Contacts]] and [[Friends]]. That would be a hierarchical structure between pages. But if to express this structure you use namespaces, you would have [[Contact/Alice]] and [[Friends/Alice]], that are two different pages and so two different nodes.

In Logseq pages are nodes so you may want those nodes to be meaningful. For example a course is something that definitely makes sense as a node, but the lecture of a course of a specific week? I think not. There is the outliner for that: you can zoom on a block and its children by clicking on the bullet point and it’s often a better alternative to creating a dedicated page.

In your place I would organize that page like this:

MGMT-364
- [[Week 1]]
   - [[Lectures]]
    - actual content
   - [[Case study]]
    - actual content
- [[Week 2]]
   - [[Lectures]]
    - actual content
   - [[Case study]]
    - actual content

So basically instead of creating dedicated pages I would use collapsed blocks and click on the bullet point to open them.

There is a breadcrumb widget at the top to browse the hierarchy.

Then with a query you can retrieve those collapsed blocks in many ways:

#+BEGIN_QUERY
{:query
 (and
    [[MGMT-364]]
    [[Lectures]]
    (or
       [[Week 1]]
       [[Week 2]]
       [[Week 3]]
    )
  )
}
#+END_QUERY

Also this way the [[references]] you make in the content of your notes will be linked directly to [[MGMT-364]] instead of one of its “subpages” created using the namespace function.

[Joe_Smoe]

@eightbt

In my use case I don’t have very unique names for my notes because it’s essentially “week # lecture notes” for every class I take. Right now namespaces don’t give me any functional benefit. I might as well name my lecture notes like [[week 5 lecture #mgmt-364]].

There’s nothing wrong with how you are dong it. You gotta find what works and makes the most sense for you. Not everybodies method will work for everyone. Though, I would say what you’re doing is what many others have found to be helpful for class lectures. There’s this video here from another user that shows how they use namespaces for class notes: https://youtu.be/Fz1EKzZZffA

Also this may help:

[bluckholl]

@alex0 thank you very much for your examples on how to index using indentation + query in each child page (+ minimal css + command hack)
I struggled to find a proper way to construct index methodology and your method is working great!

• Side note about namespace hierarchy - for whom find it useful for hierarchy (@boisjere FYI)
  Using alias, a page can be on several hierarchies, not only one.
  In fact, page name can be with short name, while the alias define any hierarchy needed.
  E.g.
  Page “LogSeq”
  alias:: KPM/LogSeq, ProductivityTools/LogSeq

(Beware of this active bug, that require re-index for every alias change… Renaming prop::alias doesn't cause the linked tag to change. · Issue #8602 · logseq/logseq · GitHub)

[AgedLace]

This use of the “alias” property is genius! Thank you for sharing it! It opens up a whole new vista of options with respect to hierarchies!

[alex0]

No problem!

I have tried to use alias that way too but it is too bugged for me. I heard the implementation of alias isn’t great, so I think it’s a bit expected and if I report bugs like those with alias the reply would be that alias feature needs a rewrite.

I use namespaces to browse queries with incremental filters so it would be nice for me if aliases worked well with namespaces.

[Cesar1]

Alex, is this right? With namespaces we lack the ablity to use the same page in two different branches of a logical tree, whereas by using your structured-block-of-only-pages approach we gain it…