Under what circumstances are [[a [[b]]] and [[a/b]] generally used

Questions & Help
1

This seems to have a significant impact

2

Welcome.

  • [[a [[b]]] supposedly helps with relationships between pages
    • check e.g. Nested references
    • it writes well the first time
    • it doesn’t read well
    • it doesn’t work well, as its implementation has issues
    • overall its usage is discouraged
  • [[a/b]] considers a term named b within the namespace of a term named a
    • namespaces are used for disambiguation
      • because many things can be named a, but only one page/file can exist with a given name
        • think of page 2024/8/14 or bookname/chapter 1
        • unfortunately, that syntax reserves the slash character /
    • namespaces are also abused to form arbitrary quick-and-dirty hierarchies
      • avoid that for sanity’s sake
      • the coming database version will provide a different feature
  • the suggested alternative approach is to use properties
    • Typically, the dependent page should have some property with the independent page as its value:
      • For [[a [[b]]], [[a]] should have some property of value [[b]]
      • For [[a/b]], [[b]] should have some property of value [[a]]
3

Thanks for explanation. I didn’t actually know this was a thing generally :sweat_smile:.

Could you give me an example of the above. I’m wondering if I’m doing it :grimacing:. What were you thinking of :thinking:.

4

Here are two purposely extreme examples:

  • projects/work/Project1/clients/loyal/John

  • management/time/goals/longterm/goal1/todos/pending/task2

You may be tempted to “fix” them by removing some levels, but all these levels are wrong, i.e. they don’t namespace anything, they just impose hierarchy. There is a scenario where e.g. goal1/task2 could be valid, but it’s still something to avoid.

5

Ah I see. Ok ta I have fallen foul of that mistake.

I think in both of those situations (or at least more realistic situations) I would probably just split them up into different tags as the hierarchy is basically pointless.

I recently attended an annual convention and realised I had a tag called something like [[convention/2025/Team/Rota/Issues]]

Whereas what I should do is have [[convention/2025]] [[Team/Rota]] [[Issues]] or something similar.

After all [[Issues]] is reusable elsewhere.

That’s possibly not the best split but it’s at least better.

When we get to the DB version I’m going to be having #issues as a NewTag with properties like a task but that’s a different story.