Add support for link types

[davecan]

Yes, exactly.

Niklas Luhmann had one golden rule when creating his notes: Each note had to be related to another note somehow when it was added to his system.

I’ve found this to be an extremely important heuristic to apply when creating notes. If a note is added without being linked from somewhere then it is an island in the sea of knowledge, disconnected from everything else and potentially not to be found again. Intentionally creating at least one forward link expands the web of knowledge in my knowledge development system.

(Exceptions are made where appropriate, e.g. daily notes are not linked “from” anywhere at the time of creation because they exist in a folder in a chronological order, so they are already “linked” by time in a sense.)

More complex inter-note relationships (beyond the point-to-point relationship) can be captured in external outline/structure notes. For example, a note that collects a series of principles together in a particular logical sequence, with each principle being itself a link to a separate note. The principles themselves are standalone units of thought, interlinked with each other and with other notes as appropriate, while this “external” note creates a particular ordered arrangement of the principles as they relate to a single topic.

Organic inter-note relationships are like traversing a graph node-to-node, while the outline/structure notes are like looking at the graph “top-down” and selecting a subset of the graph into a particular relationship.

(Or, for a video game analogy, switching from first-person view to a top-down map view)

[tuckytoo]

This is a great idea.
Can you share your flow for doing footnotes? Is that a plugin?

[tian]

Thanks.

I don’t use any plugins, or [[links]] in the body text, and exclusively use footnotes [^1]. This constraint/consistency might not be appropriate for everyone.

For the footnotes, I define 5 tag types:

1. distillation - Linking source materials to my own wording of the concept. (there may be many sources contributing to a concept). e.g. wikipedia article for cat; and the cat owner’s association of why cats are good pets.

2. formulation - Linking concepts to my own extrapolations. e.g. my claim that cats are good, and that the world would therefore be a better place if everyone had a cat.

I also permit 3 relationships between concepts (which form an ontology):

1. variation - Where similarities are defined. e.g. cats are similar to dogs; and maybe rabbits.

2. aggregation - Cat is actually “a type of” pet. Cats are also a type of big cats, like tigers and lions. (taxonomy)

3. conflict - Doesn’t really apply to concept of things; more appropriate to concepts of theory, e.g. maybe the world wouldn’t be better with more cats, as they’d somehow be a nuisance in large numbers.

Workflow is quite simple:

1. Copy and past stuff into the sources folder - each page being a single article.
2. Identify concepts - each page being an ideal (similar to zattlekasten).
3. Link everything together
4. Spot patterns and create new ideas

Here’s an example of a footnote: [^1]: #distillation [[link-to-source]] - I am using # to “tag” the footnote, hoping that in future someone will write a plugin to manage this

The relationships I’ve defined suit my purpose well enough, however depending on your needs, you will want to think about the type of relationships you may want to capture.

My only advice is to have a “#unsure” tag. Don’t try to architect the unknown - go forth and embrace uncertainty - sometimes architecture is easier in hindsight, and consistent usage of “#unsure” means that you can easily identify the pages you need to fix. (They will show up in the “Tags Panel”).

[jokysatria]

I prefer heading as link types. Headings give natural context (relation) and it’s enough for me.

For example in note named car:

## History of car
The first working steam-powered vehicle was designed
—and quite possibly built—by [[Ferdinand Verbiest]], 
a Flemish member of a [[Jesuit mission]] in [[China]] around [[1672]].

And the graph view will show something like this :

[[Car]] – History of car → [[Ferdinand Verbiest]]
[[Car]] – History of car → [[Jesuit mission]]
[[Car]] – History of car → [[China]]
[[Car]] – History of car → [[1672]]

And because I’m a bit lazy to type for each link relation, hehe.

[Skyphi]

Interesting reading this. Implementing link types would take Obsidian to a whole new level of greatness. Hope this happens in some shape or form.

Been looking into Tinderbox, and especially Beck Tench’s wonderful concept map tutorials using that program. Of course Tinderbox is a lot more advanced than Obsidian and is much more than a note taking app. Still, Obsidian has the advantage of being more future proof (with markdown) and being a simpler, more friction free writing platform. Would love to see some of the link relationships and concept map features from Tinderbox be implemented in Obsidian.

[ZacLockwood]

Use case or problem

Put simply, I want to be able to assign “link groups” to my internal links, so that I can specify how my notes are related and toggle them in the graph view like this:

Notice that this does not change which files are visible, only how they are connected.

I want to toggle link visibility, not file visibility.

I was able to find a somewhat similar request from about 6 months ago, but I believe my modular approach to solving the problem (explored below) is worthy of its own thread.

The other thread: [Filter outgoing link visibility in Graph View]

Proposed solution

My suggestion would be to update Obsidian’s internal-link syntax to include the option of assigning a “link group” by using a special separator. (I’ll use two colons :: for my demonstrations, but any reserved separator should work fine.)

For example, in a file titled “John Smith” you could write:

[[Jane Smith::Family Members]]

This way you are linking John Smith to Jane Smith (as usual) but you’re also specifying how John and Jane are related.

With a few links in the “Family Members” group, you should now be able to isolate and visualize family relationships in the graph view, like so:

To expand on the example, we may also want to track our friends’ interests, separately. We could do this by creating another link group, titled “Interests”:

[[Snowboarding::Interests]]
[[Painting::Interests]]
[[Personal Knowledge Management|PKM::Interests]]

Now we can toggle “Interests” in the graph view as well!

Notice that in some cases, toggling link visibility causes some file nodes to appear / disappear. This should only happen in edge cases where the presence (or absence) of a link causes the effected file to meet (or fail to meet) the current filter criteria.

Examples:

• Turning off all links to a non-existing file should cause that node to disappear.
• If orphans are disabled via filters and a file becomes an orphan (due to all of its links being disabled), that file should disappear until its links are re-enabled.

Finally, each link should only be allowed one “link group” assignment. That way we can have as many groups as we want and toggle them on and off, independently, without clashing or ambiguity:

Current workaround

For the examples above, I was able to write my own utility that uses a regex replacer to disable / enable specific types of links across all of my vault’s files. This works well enough, but I consider it a poor solution because it relies on modifying the files, somewhat destructively.

If it were possible to write a non-destructive plugin for this feature, I would absolutely do it. But since the best solution requires an update to the internal-link syntax and graph view functionality, I believe this needs to be implemented natively.

Rationale

Since links are a first-class citizen in Obsidian, I believe this feature should be considered essential core functionality.

My rationale for this request is that not all relationships are the same. So we should be able to identify, store, and visualize types of relationships, not only that two notes are related “somehow.”

I believe this feature would be massive for personal knowledge management, because it would enable users to heavily link their files without the threat of mass visual clutter. It would allow us to create multiple ways of organizing and visualizing relationships between ideas.

Personally, I would use this feature every day.

Call to action

If you like this feature idea and you are not a developer for Obsidian, please give this a thumbs up so the developers will find it!

Thanks for reading!

[alltagsverstand]

Have a look at the new Juggl Plugin (features and further documentation here): it already provides basic functionality for this and as far as I understand the further elaboration of this feature is one of the most important topics on its roadmap!

[ZacLockwood]

Thanks for the link!

I’ll definitely get some use out of that plugin, as I love the idea of graph workspaces. But I’d still like to see “Link Types” supported natively.

It seems too fundamental as a feature to be excluded from an app where links are meant to be first-class. Plus, the native graph view is much faster and more enjoyable to use, at least for myself anyway.

Appreciate your response!

[cristian]

It is not trivial to agree in representations of ‘link types’, there are many ways to do so. Moreover, one could also want more complex things, such as attributes of the links themselves.

If you need to express more, how to do it without complicating things? I don’t know.

I personally experiment with this format:

<< family member of [[Jane Smith]]>> since ‘2010-03-15’ .

That Means ‘this’ has a relation ‘family member’ with [[Jane Smith]], and the relation has a date.

Or

<< [[chocolate recipe]] include [[eggs]] >> quantity ‘3’, kind ‘ingredient’ .

But would it be good for everyone? Probably not

I think if we make use of the fences

```using_the_syntax_we_want

```

We don’t need to change standard markdown…

[ZacLockwood]

That’s a good point. Different people will have different use cases and will want to approach it differently.

I suggested the [[Linked File::Link Type]] syntax because I felt that it fit Obsidian’s current style, similar to [[Linked File|Alternate Display Text]] and [[Linked File#Specific Header]]. But admittedly, I don’t know much about what is considered “standard” in Markdown.

That said, I wrote the above post as a separate feature request, before I was aware of this thread, and it got merged in by one of the moderators. So that’s why my suggestions were hyper-specific to my use case: Simple link groups that can be toggled in the graph view.

Maybe that’s just me being a minimalist

Either way, you’re right: The best solution will be the one that is modular and accommodates everybody’s needs

[cristian]

@ZacLockwood

I suggested the [[Linked File::Link Type]] syntax because I felt that it fit Obsidian’s current style, similar to [[Linked File|Alternate Display Text]] and [[Linked File#Specific Header]]. But admittedly, I don’t know much about what is considered “standard” in Markdown.

And it feels natural for others too, it seems it’s already used in Semantic Media Wiki

@msteffens

[[supports::LINKID]]
[[refutes::LINKID]]
[[is confirmed by::LINKID]]

Double-colons as a delimiter for a link type prefix are already used by other tools (e.g. Semantic MediaWiki ) so this would ease interoperability.

I think the ::, comes from some programming languages, where

foo :: a 

It’s read: “the name foo is a value of type a”.

[msteffens]

IMO, having the link type in the front of the link ID has a few advantages:

• most importantly, [[agrees with::LINKID]] (i.e., “this note agrees with the linked note”) reads much more natural than [[LINKID::agrees with]]; the latter may even be confusing since it looks as if it has the reasoning backwards (“the linked note agrees with this note”)
• the link ID may already be followed by an optional link title or heading reference whereas the position in front of the link ID hasn’t been occupied yet
• speaking of other tools, I have implemented the [[link type(s)::LINKID]] syntax for my own app, and AFAIK @Emile is also thinking about supporting this inline syntax for his Juggl graph view plugin for Obsidian.

[ZacLockwood]

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

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

---

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.

[msteffens]

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]]
[[Consequences::LINKID]]

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.

[ZacLockwood]

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

[cristian]

@ZacLockwood

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.).

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

@ZacLockwood

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.

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.

@msteffens

the link ID may already be followed by an optional link title or heading reference whereas the position in front of the link ID hasn’t been occupied yet

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 .

[Rickykey]

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)

[malecjan]

@Rickykey Would the following request solve your issue?

Option to show only non-reciprocal backlinks

If your notes have lots of links, the backlinks panel can be cluttered with notes that already have explicit links. It could be useful to have an option (either a setting or a simple checkbox in the backlinks panel) to only show backlinks to notes that AREN’T linked from the current note. This would let you solidify connections between related notes.

[Rickykey]

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.

[crab1]

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%