Different page names, same concept

Hello everybody,
I have (I suppose) a newbie question. I use logseq to maintain my technical notes. I try to use short pages with concepts for the sake of clarity. But is very common that some concepts have different meanings in different contexts and as a consequence, I have “collisions” in the name of the pages. I have been searching for a solution and I suppose the better option is to use hierarchy pages to add context but this comes with the repetition of all the routes in the hierarchy, which is sometimes quite redundant, for example, if you are writing a page of a topic in the same context.
For example, I’m writing a note (page) about features in a programming language so I have a paragraph enumerating these features in a language. All the features in the table are related to the same language but these features are present in other languages. If I use hierarchies, the paragraph looks like this:
Main features of X language: [[x/a]], [[x/b]… [x/z]]
Main features of Y language: [[y/a]], [[y/c]]…
Is there any way to avoid this?

Thanks in advance

1 Like


What you have is an early but advanced question. Logseq itself doesn’t dictate any particular way of doing what you want.

  • It is not clear what you mean by “clarity”.
    • On first look, both pages and blocks have the same clarity.
  • If both [[x/a]] and [[y/a]] are true concepts within the same graph, then they always need disambiguation, and namespaces are necessary.
    • Though they should be short (rarely more than one level).
  • But if the true concept within the given graph is [[a]], it should not be specified with context concepts.
    • Should instead put any context concept somewhere in the …context, either:
      • in a separate reference or tag, e.g.:
        - Main features of [[x language]]: [[a]], [[b]], ... [[z]]
      • in an ancestor block, e.g.:
        - [[x language]]
          - main features: [[a]], [[b]], ... [[z]]
      • in the respective page, i.e.:
        x language.md
        main features:: [[a]], [[b]], ... [[z]]

This works for me by combining hierarchies and aliases … so If I have a page


and this concept is also used elsewhere

You can add aliases to the page above in its first block eg.

alias:: Python/OOP/Encapsulation
alias:: Javascript/OOP/Encapsulation
alias:: Encapsulation

I’m using Logseq 10.9 and this technique has worked well.