At first, I must confess that I was a bit surprised by Logseq’s aliases, like @cobblepot …
My main use for aliases was to hide my file naming convention (in obsidian), so that [[director.Steven Spielberg]] is displayed as [[Steven Spielberg]] and [[vg.1stperson.Quake]] looks like [[Quake]], while I can still search for director. or 1stperson as a substitute for filtering. (this workflow is kind of broken in logseq currently, see below).
For this specific use-case, I’m all for 1-to-1 alias=page…
BUT after a while, I also see interesting use-cases and nice perspectives for the “logseq” way, so here’s some thoughts:
similarities with obsidian’s aliases:
currently, the core features of obsidian’s aliases (in line with @cobblepot’s vision) are retained :
- we can link to a source [[page]] using either [[page]] or [[aliaspage]]
- we can see the same content in [[page]] and in [[aliaspage]], BUT we need to read both the page content AND the linked reference (there is no need to go back and forth between source page and alias page to check for missing content as everything is on both pages, but split into different sections)
This could be improved by :- putting the alias blocks at the top of the
linked references - adding a label (or any visual indicator such as an icon or color) to separate normal linked refs from aliases’ linked refs
- putting the alias blocks at the top of the
current limitations
-
afaik, aliases are not immediately available in search or autocompletion (the alias page should have content so that the file is created and added to the autocompletion/search list) : this limitation renders my filename obfuscating workflow useless (trying to use aliases to hide my file naming convention)
→ maybe, aliases should be immediately available as autocompletion suggestions (even if the [[aliaspage]] file has not been physically created or is still empty) as soon as they are mentioned, as opposed to a standard page link ? -
a couple of bugs/issues, like GH issue #1006 make it difficult to have a global view of the whole content split between page content and alias linked ref (the bug is that source page’s sub-bullets appear as top-level blocks and thus, we see duplicated content inside the linked references section)
-
as @tienson suggested, an option to disable the clickable link to [[aliaspage]] from the source page could streamline the workflow if aliases-as-pure-synonyms are all you need.
However, once created, the alias page would still be accessible via direct search or page link, so the user could inadvertently create separate contents between alias/source ?
-> in this case, maybe disable writing in the alias ? or provide a WARNING when the page is opened and the option is activated
differences with obsidian’s aliases:
we can add different content in [[aliaspage]] and [[page]], like contextual information relevant to a specific language or topic. some use-cases:
-
it could enable umbrella concepts or hypernyms/hyponyms workflows, that could be super useful in a project/task context like: [[clients]] has aliases [[mrBoo]], [[missJune]] or [[tools]] aliases [[hammer]] [[saw]] so that:
- on [[20201227]] I need to buy [[tools]]
- if I go to [[hammer]], I will see the backlink to
[[20201227]] I need to buy [[tools]]without the need to writeis part of [[tools]]inside the [[hammer page]] - this is probably out of the scope of normal
alias-ing, but I can see it becoming very useful in some projects as it’s faster to create categories this way
-
or for instance : movies can have multiple titles (depending on the country) or editions [[star wars]] / [[La Guerre des etoiles]] / [[star wars IV : a new hope]] . I will generally refer to [[star wars]] in most of my pages but I can still add specific infos regarding [[star wars IV: a new hope]] like
han solo should be shooting first. orStar Wars was retroactively titled Star Wars: Episode IV – A New Hope in 1981in this specific alias page.
I could add everything in [[star wars]], but the flexibility to have different content in alias pages is actually a way to be more accurate, as I can split content relevant to a specific version into a specific alias page. -
[[someone]] alias [[someone.personal]] [[someone.tasks]] [[someone.quotes]] [[someone.games]] would enable different pages relevant to specific aspects of a person in different contexts. (again , everything could be bullets inside a single page, but until we get the
everything is a blockparadigm, this may be a useful workflow in some situations)
I realize this may sound more like categories: or topics: rather than alias: , but in real-life usage, this seems to be efficient and to work.
That being said, I’m actually very open to hear/see other opinions on this.
I can see the current aliases being useful in a number of different workflows : to help contextualize, to highlight specificities (after all synonyms have nuances, else ,there would be little interest in usings synonyms) , also later on, hopefully I will be able to turn my file naming convention into readable titles in Logseq…
If one wants to limit the feature to behave like obsidian’s aliases, then it’s already possible to have a similar result (albeit, with a slightly different display for content)
so to sum up my view:
once again, I’m delighted to see Logseq trying to find its own way instead of blindly copying features… to the point where I almost regret that we can’t direct link to [[alias]] and [[page]] separately, as it was previously the case.
Maybe an optionnal config setting to restore the previous behavior so that we can experiment further before making a definite opinion (or a branch) ?
