Using Hierarchies or Is there a better Way?

Questions & Help
1

I have been a heavy Wikidpad user for the last decade. I have about 10,000 pages in that. It has a lot of similarities to Logseq from what I see but I want to make sure I’m not imposing my organizational structure on Logseq in a way that could be done in an easier way natively.

So on that note - with hierarchies…

I organize things in Wikidpad like this. If I have a course, let’s say Marketing 101 with Bob Jones and I have several courses with Bob Jones.

I’ll create a hierarchy in wikidpad as follows (using Logseq format) [[Bob Jones/Courses/Marketing 101]]

Then if I have another course I’ll do the same

[[Bob Jones/Courses/Marketing 102]]

Then if I have a lesson I will add

[[Bob Jones/Courses/Marketing 102/Lesson 1]]

And if I have homework that I did I will add

[[Bob Jones/Courses/Marketing 102/Lesson 1/Homework 05-10-2022]]

Etc. etc.

I have started to do something similar in Logseq but I’m wondering if I am being redundant and if Logseq can organize this without me doing the hierarchies.

What’s a best practice on this with Logseq?

Is it better to create individual pages for all these sub items or use the bullet features more often? I guess the issue with the bullet/node is how do I easily insert those without knowing the name (or beginning of the name of the node)?

I think the having the bullets be nodes is interesting but I don’t see where those would be used easily but I guess that’s another question for another post. (Could also be that I’m used to dealing with pages).

2 Likes
2

How you would search for this information later?
I think you should use a structure that suits your personal needs and will help you find information later. For example, if you search for this course later, would it be helpful to start with the author, then look for the courses subpage, etc.? Will you search the page only by the course title or by the author’s name? If only by the name of the course, there is no reason to include the author’s name in the title of the page, unless you have multiple courses with the same name.

How would I structure the information?
Since the structure of notes in Logseq is very atomic, and I like the definition of pages from the official documentation: “Logseq pages are nothing more than a collection of blocks”, you can place and move blocks in any way that suits you personally, but trying to link them to contexts and other thoughts. Personally, I would put the information from the course on the “Marketing 101” page. If the course were large and filled with useful information, I would divide the course into lessons with meaningful titles, such as “Marketing 101/01. Marketing Philosophy”.

Page properties
To the main Marketing 101 page, I would add a bunch of page properties, like author:: [[Bob Jones]] type:: [[course]] . This will give you the ability to find the link to the course in the backlinks of Bob Jones’s page, filter them by “course” using the UI, and get links to all of that person’s courses or your thoughts about them.

Links and tags
And in the process of writing notes, I would try to add as many links and tags that are meaningful to me to each item of the list, so that later I would be able to find individual thoughts from the course in different contexts.

2 Likes
3

I use properties for this. So in the course page, in the top block:
type:: course
teacher:: [[Bob Jones]]
title:: Marketing 101

info about the course here in the body.

Then in the lesson page, at least this info:
type:: lesson
course: [[Marketing 101]]

Info and notes from the lesson go here in the body.

This way the lessons have links to the courses, and you can have a query in the course page to show all lessons for that course (maybe even transclude them, depending on how long they are). And you now have a page for the teacher, which will have backlinks from all their courses.

4 Likes
4

Hi @Musonius, I’ve never heard of Wikidpad, but found it interesting that you used a wiki-style notebook with hierachy.
I’m relatively new to Logseq, but there is no hierachy, it’s all about using links, tags and properties.
So yes, the folder structure (if that’s what you meant) is redundant.

5

@Gary_O, this is exactly what I need to better understand.

Currently I’m using tags for everything. Is there a beginner tutorial out there to help me understand properties? in this case it’s about doing a course, but how do I open that up when I, like @Musonius, have a ton of notes covering many subjects?

6

I’ve had more time to play with Logseq since I originally posted it.

I am using a lot more tags.

The interesting thing with Wikidpad is that I had a very similar set up to what Logseq does, just without the blocks.

I would use a monthly page for my journal [June 2022] for example (no double brackets like Logseq) and then I would create anchors within that page for each day ie (anchor: 06302022) and then make my entry and of course link out using wikiwords to whatever new pages I wanted to create.

It had a parents and child feature, so I had backlinks too if I wanted.

Tags weren’t as easy as I would have to type out each wikiword on a page with brackets if it was inline or at the top of the page, but it was still fine. The wikiwords would work just like the tags do on Logseq if I used the child or parent code in a page. Only difference was all the pages would be listed alphabetically and it would just be page names and not blocks like on Logseq.

I did use a lot of the hierarchical wikiwords on Wikidpad and I have started using some on Logseq. It does make some things easier to find without having to use queries.

For example - if I have a set of pages set up like this…

[[Travel/2022/Vegas]]
[[Travel/2022/Florida]]

This makes it easy for me to write about and find things related to that vacation.

I just start an entry on Logseq in the journal…

[[Travel/2022/Vegas]]
* Purchased airfare for $xxx round trip
* Booked room at xxx for $xxx

I can journal things I do on that trip the same way and of course tag things on any block if something comes up that I might want to look at later. ie - #expenses, #goodconvo, #favoriterestaurants, etc. etc.

Then I can just search vacations and I will see the hierarchy at the bottom and go wherever I want.

Might be an easier way, but I’m not that fluent with queries yet and this works pretty simply.

I’m really liking Logseq. Still figuring out new ways to do things every day. For example, I just figured out a great way to process non-fiction books that works for me. It’s fun to experiment with and it’s not that hard to change things around if you decide later something is working.

7

I’m not sure re: tutorials. Have to google around I guess.
But I can say that each property value I showed above becomes a sort of virtual page, with all of its backlinks listed below it. So just click on “Bob Jones” to see all notes referring to him, the course title to see all the notes for that course, etc.
You could also make a query in the course page to show all the lessons for that course. Queries can get complex (the syntax is strange) but the Logseq discord #queries channel is very helpful.

1 Like
8

We are having a discussion on different hierarchies on another thread

The goal is to get support for polyhierarchies, so that “Vegas” can also be classified to be part of “Cities” and “NV”.

At the moment, one has to pick one single hierarchy (as you did for Travel), and then add all other classifications with (a potentially large number) of tags.

1 Like
9

I think hierarchies are not supposed to be used like that on Logseq…

It took me a while to realize it but now I use tags and properties for everything and hierarchies only for the following use case that is better described by examples:

[[My New Book Title/Chapter 1]]
[[My New Book Title/Chapter 2]]

[[An Online Course/Lesson 1]]
[[An Online Course/Lesson 2]]

That can be more compact:

[[My New Book Title/1]]
[[My New Book Title/2]]

[[An Online Course/1]]
[[An Online Course/2]]

As you can see the child names makes sense only if associated with a parent page.
Other examples:

[[Weekly meetings/1]]

[[Logseq/bugs]]
[[Another software project/bugs]]

[[A University course/questions]]

[[A knowledge sector/definitions]]

[[A math branch/theorems]]
10

Hey @Musonius, on the Logseq blog ramses is promoting an event focussing on Queries, in case you haven’t seen it

1 Like
11

Thanks @alex0, gonna spend some time trying to make sense of this, TY for the explanations!

1 Like
12

Alex,

This has crossed my mind too.

Like I have [[Marketing/Psychology]] that I use as a tag, but then I wonder if it would be better (longterm) to use [[Marketing]] and [[Psychology]] separately as tags.

It’s flexible and could be done many ways, but I think we are all looking for optimal ways to organize.

13

For things like that I would use tags and page properties. I use [[parent/child]] only if child is a word that makes sense together with a parent and in other contexts it deserves another page. In my examples I put this to an extreme by using 1,2,3,etc as name pages to refer to lesson, meeting, chapter number.

You can use emoji too. For example [[Logseq/:lady_beetle:]] to track bugs in Logseq.

The [[Marketing/Psychology]] page makes sense only if you are referring to psychology in the context of marketing. In that case [[Psychology]] would be another page on psychology in general.

Then you would tag a block or a page with [[Psychology]] if you mean psychology in general or [[Marketing/Psychology]] if you mean psychology in the context of marketing.

Doesn’t this approach draw a clear line between hierarchies and tags use cases?

2 Likes
14

I mean psychology specifically applied in a marketing sense. So yes, I think we are the same page.

The worry I have is if I might miss things later that I can query by using hierarchies vs keeping them separate. ie - maybe using #marketing and #psychology separately would pull better results once I delve deeper into queries? (I don’t know).

On my Travel example - I’m thinking that maybe using properties would be better to use in that scenario?

Instead of Travel/2022/Vegas and Travel/2002/Florida

I could just have a [[Vegas 2022 xxx Conference]] and then properties in there that identify important data. Then make a page that called "Trips’ and do a query and table that shows all of them?

Not sure though as it’s nice to go to Travel and scroll down and see the hierarchy too.

Two ways to skin a cat? Or are there things I’m not foreseeing that would make one way better than another?

15

There are page properties for that:

Trip in Florida (page title)

Type:: trip
Year:: 2022
Country:: Florida
Places:: [[City A]], [[City B]], [[Monument C]] ...

This is the best if you want to use queries because pages basically becomes entries of a database.

A query could list for example all the trips to City A in the year 2022.

Using [[Marketing/Psychology]] where it makes sense doesn’t stop you from using it together with [[Psychology]] if something fits both psychology in general and psychology in the context of marketing:

tags:: [[Marketing/Psychology]], [[Psychology]]

Then with queries you can filter pages that contains at least one of the two or both at the same time.

Isn’t this flexibility cool?

1 Like