Would love unidirectional aliasing!

So a bidirectional alias would be I think what’s already in org-roam ([[pct]]=[[Perceptual Control Theory]]=[[perceptual control theory]]=[[PCT]]). Unidirectional would be saying that every time I refer to [[PCT]], that shows up in the backlinks for [[Behavioral science theories]], but not the other way around. Allows for a bit of hierarchy to be imposed.



Is it about seeing the link in the backlinks or just to show the preferred/canonical note? (a kind of hierarchy, as you said).

If it’s the latter, maybe you can create both notes (“perceptual control theory” and “PCT”) but make a link from one to the other, but not back. In this case, it would be the classic wiki style to make an alias.

Sorry if I didn’t understood your question… :slight_smile:

PD: on second thoughs, maybe the #+ROAM_ALIAS could help, although it’s in the same note.

Just so easier to understand and discuss, can you put this in the context of the existing OR model?

In particular, how does ROAM_ALIAS fit?

I think this is the idea:
#+ROAM_ALIAS: provides ‘bi-directional alias’ links. If I have:
#+TITLE: Perceptual control theory
Then [[Perceptual control theory]] and [[PCT]] both link back to the same note, and the backlinks buffer populates with ALL references to either one.

Having a ‘uni-directional alias’ is a bit like an index or topic note you’ve made in OR that is pre-configured to show the backlinks from the notes it references (instead of manually writing a search to aggregate them on demand).

So if I make a note like:
#+TITLE: Behavioral science theories
Then the “Behavioral science theories” note’s backlinks buffer would populate with all references to itself, but also all references to [[PCT]]. However, the “PCT” note’s backlinks buffer would ONLY populate with references to itself (and not also [[Behavioral science theories]] like it would if you used ROAM_ALIAS).

If this is right, then uni-directional aliases would basically remove a small step in viewing/aggregating links to topics contained in an index note. Is this right @ClassicRob?

I’m trying to think of the particular benefit this might offer over simply using specific strategies within the existing org-roam capabilities. For instance, you might achieve the same effect if a small function was just added to aggregate the backlinks from a list of other notes.

Would that essentially be the same thing @ClassicRob or is there something more nuanced to it?

That explanation helps @alan; thanks!

If that’s accurate, then isn’t that not, in fact, an alias at all, but more like a hierarchical tag (see this new FR for discussion)?

Or, I dunno; I start to get confused when we try to add complexity :wink:

In any case, it’s a way to express particular types of hierarchical links or associations, it seems to me.

Eh, you’re not the only one having trouble keeping track of everything.

That could work, and I see the value in doing that. I think there’s still plenty we can do with file-metadata tags, another example being #572 as was mentioned. Can someone create a topic to centralise which file-metadata tags would be useful to have, as well as the functionalities we’d like to associate with them?

The issue in good design, I think, is balancing new features against the imperatives of clarity.

This is particularly true with this problem space, lest we end up with a Frankenstein’s monster; a by-design flat graph model married to hierarchical organizing systems; where the additional cognitive load of the UX has the potential to undermine the original goal.

Despite my language, I’m not saying I have anything against this idea; I just don’t know yet until I understand it better, and how it relates to the tags FR, UX, etc…

1 Like

@ClassicRob brought this up in Slack with an interesting Roam example: Writing a link as [[self-[[identity]]]] creates both a self-[[identity]] page (the link is included, and is considered unique from a self-identity page, but that’s what completions are for), as well as an identity page.

self-[[identity]] gathers its own backlinks, while identity will collect backlinks for both. It’s a very low effort (albeit bracket-laden) way to create topic/index pages rather organically, at the least. I’m not sure if there is an extra benefit or not.

The uni-directional alias is a version of this that could be implemented in OR. I am questioning if the implementation is worth the effort, if instead roughly the same feature could be pseudo-replicated with an easy-to-use function – keep an index/topic note like you normally would, and when you want backlinks, just run a function on a header with a list of notes, or something.

This would be less mentally imposing than a whole new feature to implement and for users to learn, but I might be missing some other unseen benefit that comes with the alias construct.

Quick comment on the syntax: #+ROAM_ALIAS makes more sense to me.

That already is used for the normal ‘bi-directional’ aliases :wink:

This may sound a bit vague, but the general idea and benefit of this is to give the user an additional way to embed semantic meaning into their notes.