Page names for multiple similar events in time

To make my question clear I will need to get a little bit personal.
So I had a sick leave period from February 2021 till May 2023. And now I’m currently having a sick leave period since January 2024.
For this I have contact with a company doctor. So I have a page “company doctor” that currently holds notes for both sick leaves.
But I’m not pleased with that. The notes are about my sick leave and not my company doctor and I want to separate the two instances of sick leave to give each their own page.
I can’t have two pages with the name sick leave. The reason for the sick leave is in both case equal, so we can’t use that to distinguish.
The only distinction I can come up with is the time period.
But what type of naming convention should I apply to these two pages?
I notice resistance against using the date, but I can’t figure out anything better.


There is also the distinction of order in time. Could think of your sick leaves as:

  • a book with chapters, i.e.:
    • My sick leaves/1
  • rare historical events, i.e.:
    • Sick Leave I
    • 1st Sick Leave

I like that approach. They are related, but distinct.
I already use properties for start and end dates, which makes more sense than doing that in page names.

In my Logseq I have a namespace called Medical with sub pages for things I’m keeping track of. Like Medical/Hayfever and Medical/Autism

To keep track of everything, I make notes in the journal linking to the related subpage and add the tag #log and have a query in those pages so I can see it’s progress over time.

This is especially handy when things have a lot of events like doctor visit 1, 2, specialist 1, etc…

The problem with sick leave is that it’s often a period and I what I usually then have is a journal entry for start/end of said leave so

(Start Journal page)
* Couldn't get anything done, hayfever season has started [[medical/hayfever]] #log

(End journal page)
* Stopped hayfever medication for a week and no issues [[medical/hayfever]] #log

I love the idea mentaloid uses here and seeing things as chapter. I might extend it by starting with year and letter so in the future I would easily see what period that would be. So 2024a, 2024b, etc…

Could you provide an example note with that?

Let’s see, quick example structure here

And example of appointment I had last Friday, by using a year structure I can plan ahead and add details to the element for next season.

So the idea is that if I have some type of Hayfever in Autumn this year I can still make 2024c without it affecting the other years.

1 Like

Nice to see a whole different kind of use of this suggestion :slight_smile:

Here’s what my page actually looks like.
I don’t use the page itself for tagging all that much.

The one linked reference is for the project WIA aanvraag of which this page is the topic/reason for the application.

In the journal queries I select for journal entries related to topics related to my sick leave. So I have everything collected in one place.

As you can notice sick leave for me is in a span of months/years. So something must go horribly wrong if I have more than 1 event per year :joy:

So here’s the query I’m using on this page:

{:title [:span.h.dark "Journal"]
 :inputs [:parent-block]
 :query [:find (pull ?b [*])
  :in $ ?parent
   [?parent :block/refs ?block]
   [?block :block/refs ?page]
   [?parent :block/properties ?prop]
   [(get ?prop :datum-begin) ?begin]
   [(get ?prop :datum-eind) ?eind]
   [?j :block/journal-day ?dag]
   [(<= ?begin ?dag ?eind)]
   [?b :block/refs ?page]
   [?b :block/page ?j]
 :breadcrumb-show? false

Great to see how this is solved. Based on the examples or other info, @Siferiax is Dutch, @Bas_Grolleman is Dutch and I am Dutch too.

Do Dutch people like, use or need Logseq more then other nationalities? Interesting…

I would say no:

  • Your sample is very small.
  • When it comes to absolute numbers of users:
    • Dutch ranks relatively high:
      • probably among the top four countries in Europe
      • some countries in other continents have more users
    • but not for the implied reasons

Your example produces this path of references:
2024/06/28 > [[Doctor]] > [[Medical/Hayfever]] [[Medical/Hayfever/2024b]] > [[Medical/Hayfever/2025a]]

I personally find that heavy:

  • These two in the same line look redundant:
    • [[Medical/Hayfever]]
    • [[Medical/Hayfever/2024b]]
  • Why to have [[Medical/Hayfever]] and not [[Medical/Doctor]] or [[Medical/corticosteroid]] ?
    • If any of them ever needs disambiguation, that would be the [[Doctor]]
      • The other two are medical terminology.
    • Though it would be easier to drop the namespace from [[Hayfever]]
      • At the very least, could make [[Hayfever]] an alias of [[Medical/Hayfever]]

Of course there are many ways to syntax it, but here is my effort:

  • Concerning the use of “chapters”, I opted to keep the year out of them.
  • I would then use a query to filter by year etc.

Agree on the redundancy, I sometimes forget that Logseq will show both and then just add both to be sure. After reading, “You are not so smart” I stopped trusting my brain. :smiley:

As for the Medical tag, looking back at it I understand the confusion.

So [[Medical]] is actually short in my brain for “My Medical Issues” meaning that [[Hayfever]] would be general Hayfever knowledge and [[Medical/Hayfever]] would be specific to my personal case.

The goal is that if I look at [[Medicial]] I can see my personal full medical history, but I can limit it to specific things like Hayfever when I need that subsection of info.

[[Doctor]] in this case is to keep track of all doctor visits.

If you track everything in your journal then filtering on year should work, but when I reference something often I usually make a quick summary in the page.

That’s the problem with Personal Knowledge Management, half of the system is in my brain :brain:

Love the feedback, definitely could simplify. At the same time, my notes are messy just like my brain.

1 Like

Wise words. At the same time, that points to the solution for PKMs: to treat them like if shared with other users and their brains. Since trusting own brain isn’t very smart, the alternative would be to trust a collective mind.