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.
Nice to see a whole different kind of use of this suggestion 
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 
So here’s the query I’m using on this page:
#+BEGIN_QUERY
{:title [:span.h.dark "Journal"]
:inputs [:parent-block]
:query [:find (pull ?b [*])
:in $ ?parent
:where
[?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
}
#+END_QUERY
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
- Dutch ranks relatively high:
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]]
- At the very least, could make
- If any of them ever needs disambiguation, that would be the
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. 
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 
Love the feedback, definitely could simplify. At the same time, my notes are messy just like my brain.
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.