Add support for link types

Interesting! I actually think of it with entirely different semantics. Your way of approaching it is perfectly fine, but I’ll explain my thinking as well, since I think it provides some different advantages:

Basically, I think in terms of “Link Group” as a noun phrase (Family Members), rather than “Relationship Type” as a verb phrase (is married to).

I ask myself “What group does the linked file belong in, from the perspective of the current file?” rather than forming a sentence “File A agrees with File B.”

Some examples:

  • [[John Smith::Family Members]] - John Smith is a Family Member (to this person).
  • [[LINKID::Supporting Ideas]] - The linked file is a Supporting Idea (of this idea).
  • [[LINKID::Consequences]] - The linked idea is a logical Consequent of this idea.

The main reason I think this way is to make my system more conveniently structured for future searches.

When I come back to an old file in my system, I find it more natural to say:

  • Show me all of this note’s Supporting Ideas.
  • Who are this person’s Family Members?
  • What are the Consequences of this idea?

Rather than:

  • Show me all files linked with relationship type “is related to”
  • Show me all files linked with relationship type “agrees with”
  • Show me all files linked with relationship type “logically implies”

It is an extra mental step to ‘nounify’ relationship types (“agrees with”) into link groups (“Supporting Ideas”), but it’s an extra step that I find healthy for long-term clarity and organization in my system. It forces me to ask bigger questions about the structural outline of the information I’m mapping and how many types of relationships I actually want to track.

I much prefer to have a few organized groups (“Family Members”, “Hobbies”, “Professions” etc.) over an unmanageable number of semantic relationships (“is married to”, “is the son of”, “is the father of”, “plays the sport”, “studies the field of”, “frequently travels to”, “works as a”, “freelances as a” etc.).

Of course, this is just my way of thinking, and I’m consciously choosing to sacrifice some specificity to gain long-term simplicity and scalability.

Like I said, your method is great as well :+1:t2:

Just wanted to put mine out there as an option, in case someone else resonates with it :sunglasses:

P.S. Hilariously though, after all that explanation, I really wouldn’t mind placing the link type first as you mentioned. It makes little difference to my thinking approach, since I’m not using sentences to type my links.


Thanks for the explanation. I also think that your “link groups” would work equally well when placed in front of the link ID, e.g. like this:

[[Family Members::John Smith]]

Also note that my verb-style link types (like “agrees with”) were just examples. You’d be free to use noun-style “link groups” instead. I’ve called the latter “link tags” or “link labels”, but there’s no real difference. Even “link attributes” (key/value pairs such as [[quantity=3::LINKID]]) could be used.


Definitely! It’s really cool to see how everyone is using Obsidian / Markdown for personal knowledge management. If we can get native support for link types, it’ll be huge :grin:


Don’t forget that in tools like Obsidian, we can have auto-complete! That certainly would help limit an explosion of predicates :).

I prefer ‘link type’ first because it feels natural for me, just because the languages I write (Spanish and English) are subject-predicate-Object based, and writing the link type first won’t interrupt the writing flow.

The only thing that worries me with the notation [[Family Members::John Smith]] is that Obsidian currently parses this as:

[[__This__]] --unnamed--> [[Family Members::John Smith]]

And also might be interpreted in strange ways by other editors.

I imagine a new pair of symbols (like << >>) would not break existing functionality, such as the crucial Obsidian’s ‘rename.’

It could be used like this

<< [[Family Members]] [[John Smith]] >>

Or just embedded in the text…

and then,  << my uncle [[John Smith]] >> said...

I don’t know (I haven’t experimented with it yet).

Note: I’m borrowing the << >> from the RDF* (RDF Star) notation invented not long ago in the Semantic Web Community to describe graph data.

:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .

Use case or problem

  • In my workflow, I create permanent notes thanks to multiple literature notes.

  • I go in the permanent note, open the backlinks pane in the right sidebar, and start writing thanks to the literature notes content (From the backlink on the top, to the backlink on the bottom).

  • Since I process the backlinks from top to bottom, once I’ve processed some backlinks I don’t want to see them anymore, I just want to see the ones I haven’t processed.

Proposed solution

Solution 1

Thus, it would be cool to give “states” or “tags” that are proper to backlinks. Then, we could put some backlinks of the note containing the tag “processed” in some “backlinks folder” similar to the current ones (linked mentions and unlinked mentions) to then be able to show them or not.

To do this, maybe we could add a variable to each backlink that the user could change if he wants? (see figure)

Solution 2

Limit the solution 1 by just putting a “check” mark on the blocks of content of backlinks. If a backlink is checked, it goes in the “check” backlink folder. If it’s not, it doesn’t.

Current workaround (optional)

For now there is no workaround, really, I have to remember which backlinks I processed and which backlinks I didn’t.

Related feature requests (optional)

1 Like

@Rickykey Would the following request solve your issue?

1 Like

I would say partially! Because then I would just have to mention the litterature notes as “sources” in my permanent note. The feature you shared would then allow to make the entire notes disappear once i’ve processed them.

But I was talking about going even further, where you would process the content at the “block” level and not at the entire note level.

So in a sense it would help but not entirely. The link types would completely solve it.

For a minimum viable case: What about simply having a token within note that, if present, becomes the link (words along the arrow/edge/arc) name?
If your note contains characters between percentage signs then any outbound links get the text as the arc alias. e.g. %eat%



I would love to see that feature or community plugin in Obsidian. Could you share your current workaround with us?

Graph View is cool. In fact, it was the main feature I liked when I heard of “Obsidian” a year ago. I am a mind-mapper myself, and a Database-lover.
So, while I love to work on my Notion, it lacks so hard a mind-map structure, and I’ve tried alternatives to that.
Currently I use the Brain. and being honest, its expensive, and lets say it feels a bit out-dated in style or else, but it gets the work done as a wiki-mind-mapper.

So Obsidian sounded very cool to me. but Graph-view, a year ago, was very primitive, compared to today of course. so I didnt use it as I would like.
Nowadays, though, is more robust, and overall Obsidian is adding very quickly a ton of features (and this encourages me to keep using it).

well…so the mind-map part: Currently links keep being just some lines (with maybe arrows) that cant be edited in any way.

Maybe we could make links between Nodes to have different colors, names attached to them, or icons, or maybe even notes. ??? (a nice group of features found in TheBrain)

thanks for listening
cheers, team!

1 Like

My story is a bit similar.
I was in the market for associative notes a year ago, and the choice came down to TheBrain vs. Obsidian. I felt like Obsidian was too ripe, and so I went with TheBrain, which decently suits my needs even today.

But Obsidian has since progressed greatly, its fast, simple, with a transparent folder structure, and a nice dynamically generating graph.
I want to really use it, but the only thing that it’s really missing is types of links.

In fact, what I only really need is having just 2 types of links (hierarchical parent/child relation and some kind of free association). + Being able to filter them out on the graph.
I think they could be nicely visually distinguished by solid/dashed lines:

Having these would not hurt the simplicity of Obsidian’s architecture, but would greatly improve comprehension of the connections between the notes.


Something like this can be done through the Juggl plugin. For now, the edges are configured through CSS, but the developer plans to add this feature to the main panel.


I very much like the approach taken in TheBrain where a link is more than just a cross-reference, it is a primary entity (property holder) that can have a note and other attachments associated with it that describe the nature of the link.

It isn’t easily possible to emulate this feature in Obsidian. If I link Page A to Page B the current method to describe the nature of that link is to put it into A or B or both (bad duplication) and possibly create a block link. The only way to avoid this is to put the details of the link into a new page ©. If I then link A->C->B I would lose the direct link A->B in the graphview. If I create A->B and A->C->B I start to introduce obfuscation.

This isn’t a problem in TheBrain because the primary display is graphical so A and B appear as nodes while C is a directed arrow between them. The arrow shows that they are linked while a note attached to that link © can be used to describe it’s nature. There is no difference at all in the status of a note attached to a link compared to attached to a node.

I hope this makes some sort of sense.


Hi Zac! I love your use cases and sample GIFs illustrating them, very well done!

I just made a feature request that could actually solve both of our needs:

Here’s how this simple attributes feature would work:

I want to make this paragraph have its own class. {.foo}

Furthermore, I want to give [[This Page Link]]{.bar} its own class.


- this list
- should have
- a third custom class

Now you may be thinking, “this doesn’t solve my use case”—but it’s usable for any attributes. For example, are you familiar with XFN — the XHTML Friends Network? It lets you establish relationships using the standard rel="" attribute, so a relationship link could be defined like this in markdown:

Meet my partner, [[River Song]]{rel="partner"}.

Looking for something more specifically tailored to your Obsidian needs, like wanting custom filterable options in the Graph? If the Obsidian team implements this markdown-it-attrs feature request, then they could support your exact needs with something like the above (parsing the rel attribute for graph filters, for example), or:

Meet my partner, [[River Song]]{data-obsidian-graph-group="Partners"}

The data-obsidian-graph-group would find all unique values (“Partners”) and turn those into filter options as a group.

Additionally, this proposed feature request for markdown-it-attrs would allow for customizable aspects to lots of areas of Obsidian, using that data-obsidian-X syntax. It’s all up to what the devs would want to allow and implement, but the idea of customizable graph filters is awesome and I would love to see them implement this!


I am down for typed links, colored connections, different types of lines — whatever we call it. I have Objects (.md files) that are linked with other Objects (obviously), but some of the Objects are “GOOD” and others are “BAD”. I have a ton of them and it is confusing to see only one type of line which is in my case is
.graph-view.color-line { color: #97969c; opacity: 0.5; }

I imagine that if we have common connections as [[Object]], then we could use [[[OtherObject]]] or {{OppositeObject}} to tell the app to use a different line type.


This would also be a game changer for me! Hopefully this is something we’ll see in the future!

1 Like

I’m trying to figure out how people are currently writing link types…

I’m aware of Dataview’s Inline fields that allow writing types using the Key:: Value syntax.

# Example

is a :: proposal

Also Juggl link type support to label edges like:

- is a [[proposal]] 

Which others can be found in the wild?

Would it be possible to have connections in Obsidian’s Graph View representing notes of their own? Just like the nodes in the graph represent notes.

Coming from Kumu’s relationship maps, I miss the possibility to detail how two things relate to each other. And having notes attached to connections would be perfect for that.


I don’t quite understand. Are you perhaps describing this, where links can have a type associated with them? Add support for link types

Or are you saying you want the connection between notes to be able to have notes? Like this or something? (If you’re talking about link types, I’ll suggest merging your topic into that thread.)


Thank you for your drawing. It gets the idea through. Nonetheless, what I’m trying to describe is actually a mix of the two things you mentioned, in the sense that once a link can be/have a note of itself, it’d be possible to specify its type on such a note (via tags even).

Do you think it’d be more productive to merge this topic into the thread anyway?