Add support for link types

I think as superset of this feature, having link types makes sense too for better organisation. I used to use TheBrain (previously PersonalBrain) which had this link type feature among nodes. Granted it was mainly a mind-map type app, whereas the graph is one feature in Obsidian but I think since the core of Obsidian is still notes and the connections between them, it makes sense.

Link types can help establish certain relationships that we cannot do now like,

  • Parent - Child
  • Sibling (default as it is now)
  • Directional
  • Task/area assignment
  • Status (under consideration, ongoing, established, etc.)
  • etc.
22 Likes

Absolutely - The Brain is the gold standard as far as I’m concerned when it comes to visually linking notes. I never got into using it, however, because it is TOO visual and the text features were too cumbersome.

4 or 5 years ago I tried to hack together a bunch of d3js code snippets to basically create a poor man’s Roam/Obsidian, being text-first with a filterable, customizable, zoomable, node-centering network map, but I didn’t have the capabilities to make it anything beyond a very crude alpha.

I’m delighted to see all these text-first tools coming out now, but the graphing capabilities are nothing short of unusable. I look forward to whatever progress is made on this front - but first the basics of the editor, linking, etc… need to get ironed out. The priority, after all is on linking the content, the text, the ideas of notes, not just the notes themselves.

But even in a good interface, like Roam, people tend to be focused on the latter - linking as many low-quality, meaningless notes as possible, instead of focusing on creating good notes/ideas first and then link them meaningfully. That’s user error though - and starts to get into notions of philosophy, ability to think, have perspective, have principles and frames of references, have an actual (worthwhile) goal that can help orient your efforts, know what is actually important, and leave the other 95% of your shower thoughts either unlinked or in the shower.

4 Likes

Yet another voice for the TYPED LINK feature

According to Tim Berners-Lee, “A typed link carries some semantic information, which allows the system to manage data more efficiently on behalf of the user.”

This page sketches some of the most essential link types. Here there is much more. I was introduced to the concept of “typed links” at the first international Hypertext conference in 1987.

I still haven’t seen many decent implementations of this essential concept to building a second brain, in spite that it is essential to the semantic web. Drupal has a dev. “typed link” project

The following illustration of typed link is from "Towards a Standard Graph-Based Data Model for (Engelbart’s) Open Hyperdocument System."
Screenshot 2020-10-12 at 13.11.11

6 Likes

While it is very nice to see connections between different notes/subjects, it is somewhat lacking (in the context of graph view) that you can’t immediately point out what links two nodes together.

Sometimes you can recall just by association.
And sure, you can always get into the notes and figure out what gave birth to the coupling.
But wouldn’t it be nice if you could name a certain edge and have the name pop when you hover over it with the cursor ?
I think such feature would increase the value and usability of graph view significantly

6 Likes

Use Case:
As a User I want to create relations between notes by using a plain markdown syntax or markdown extension.

Possible Implementation:

  1. In Plain Text via Markdown Extention:
    Like using an markdown extension like Link to Headings with [[Note1#Heading1]] or Alias [[Note1Titel|DiplayText]] there could be a further extension like [[Note2::relation::]]

  2. In Graph View:
    Sample:
    Note “Mother” contains a Wikilink to [[Father::married to::]] then the graph shows the following relation:
    Mother ---- married to —> Father

9 Likes

Here’s a relevant discussion that we were having over in Foam about link types, use cases, implementations etc…

1 Like

Linking is the most valuable feature of obsidian and it is great for it’s simplicity.
However, I believe it could still be improved.

Considering linking title such as [[My Note | My Title]].

This could be used in the graph view to name the like.

(source note) --[My title]–> (target note)

The idea is that the title we give to the note’s link captures parts of the link semantics.

Rdf or linked types are and will be the game changer for personel knowledge management systems. İmagine a plugin run sparql querries on your pkm. İf someone also add variable functionality. (Put here a meme says “shut up and take my money”). :slight_smile:

1 Like

Hello,

Any Idea on how a link name would look like?

Or how to write them while in a note?

How about:

[[this is a link]]
[[this is a link|with different text]]
[[this is a link|with different text|exampletype]]
[[this is a link||exampletype]]

That’s easy to type, differentiates easily in edit mode (to my eyes anyway), can be easily search and replaced/grep’d for bulk edits, and contains all of the link information inside the link brackets (which appeals to my sense of info heirarchy organisational tidiness :slight_smile: )

3 Likes

There’s a complexity here to do with the linking direction and rendering in the graph view. Your example:

Mother ---- married to —> Father

should actually be rendered:

Mother <-- married to —> Father

Or possibly without arrow ends at all. It makes sense to read that particular relationship both ways. But [[Child::gave birth to::]] only makes sense as:

Mother ---- gave birth to —> Child

In the Mother note you might also want to write [[Father::proposed to::]] which I would read as:

Mother <-- proposed to — Father

And yes, I know that could be interpreted the other way around as well - Mother proposed to Father. My point here is that it’s ambiguous.

PS Don’t get me wrong here, I want link types rather badly. I’m just talking thoughts out here to try and refine how they could/would work.

Hi Stolt,

I’m trying to find how Tiddlywiki, Tiddlymap, Graphviz, etc represents link ‘types’ in markdown, but I cannot find any examples.

And what do you mean with “full feature set of network graph” ?

Hi! Thanks for the examples:

[[this is a link]]
[[this is a link|with different text]]
[[this is a link|with different text|exampletype]]
[[this is a link||exampletype]]

I think they are easily parseable and won’t break things around. I’ll use them in the meantime :slight_smile:


Regarding linking direction,

If you declare:

Mother ---- married to —> Father

I believe it should be rendered just like that, in one direction.

Unless your system has a rule about the property ‘married to’, for example:

If x is married to y then y is married to x. (symmetric)

Then it can infer: Mother <-- married to —> Father

Link types allows reasoning, so you don’t need to type all knowledge explicitly

I really want link types too,
and I’ll start writing them to parse them in the future with Obsidian or a plugin/script

1 Like

Consider also the Semantic MediaWiki syntax where the optional property portion of the link is actually a prefix like if your Berlin.md page had a link:

[[Is Capital of::Germany]]

…which linked to Germany.md and established the relationship:

Berlin --> Is Capital of --> Germany

So you have two notes - ‘mother’ ‘father’
And you’re looking at links. Just think how many there will be of different types. True that each one you add will be specific when you add it, but the link network will be awash with them.
My feeling is that, for something like this to be added, it ought to include ways of dealing with issues like these.
Could be a linktype equivalent to a MOC list, where ‘mother’ ‘father’ are the notes at the top and there’s a list of all link types that have been identified between them. Married could have at least three possibilities - religious, civil, legal. Everything would depend on what the user was interested in.

That little example has two notes and one ‘explicit’ link. The link in the opposite direction is inferred through a rule, not explicitly written down. It was an example of how to have bidirectionality and avoid duplication.

I don’t understand why the number of types (link names) would be an issue, I believe users can figure out how many different types they want, and how to use them.

Do you mean to assign link names which can be also a Note? That would be awesome! It would keep things consistent. Having ‘link types’ as regular notes allow to explain them and relate them together. Perhaps even write down properties such as symmetry, transitivity.

Example:

Note ‘Mother’

# Mother

This [[Is a::Person]] [[Married to#civil::Father]]

in the note ‘Married to’ (which is a type)

# Married to

This is a [[Is a::Type]] and [[is a::Symmetric relation]]

## religious

Explanation...

## civil

Explanation....

That way of writing types is really cool! thanks!

1 Like

I’m considering using the link-to-header syntax right now, actually, since it sort of already works and I can grep them etc. So in the Berlin.md case I can write my link like:

[[Germany#:is capital of]] and it still links to Germany.md.

It renders in the HTML as:
Germany > :is capital of which also isn’t so bad.

The : bit after the # tells me I’m doing this for semantic linking reasons and it also won’t conflict with any existing headings in the document.

2 Likes

I’ve also discussed semantic links (or “qualified links” as I’ve previously called them) over at the zettelkasten.de forums. There, I’ve suggested the following link type syntax:

Similar to semantic citations used by Pandoc Scholar, Markdown links could incorporate a relationship type like this:

[[type:link]]
[[link description|type:link]]
[link description](type:link)

Examples:

The ideas in this note are further extendend in [[is_extended_by:20201113]].

These statements question the conclusion that [backlinks are useful](critiques:Why_backlinks_are_useful.md)

Reading the comments in this thread, I think that the use of double colons (i.e., [[type::link]]) may be even better, since its used elsewhere already and is likely easier to parse. Also, a rather unique sequence has less chance of colliding with other uses (e.g., single colons in bibliographic citekeys, like miller:2019).

For bibliographic citations and links between literature notes, the CiTO ontology could be used which already offers a comprehensive set of relationship types. Software could offer these relationship types via autocompletion when composing a link.

The use of semantic links would allow software to label connections in graph visualizations, or to filter a graph by a certain relationship type. These are just a few examples, of course.

IMO semantic links have a huge potential to further advance what knowledge management software can do.

1 Like

The semantic relationship between [[wiki links]] is always present in the sentence where its used. For example,

  • [[Berlin]] is the --capital of–> [[Germany]].
  • The [[Cookies]] --are inside–> the [[Jar]].

So I feel, we could simply highlight the part of sentence that describes the relationship (as shown above) and the resulting graph could look like this.
sample

I feel this could be an elegant solution for providing context to the links.

For a cleaner look, we could even choose to hide the arrow syntax in preview mode and only use it to identify and display the label in Graph View.

what do you guys think?

2 Likes

Obsidian supports YAML frontmatter since v0.9.16 (when it introduced aliases).
Maybe typed links could be supported in this frontmatter? Eg

---
aliases: [alias1, alias2]
topic: [topic1, topic2]
capitalOf: [Germany]
author: [author1, author2]
---

Access to frontmatter is supported in the Obsidian API (through CachedMetadata). So a plugin could tackle this, maybe! In this example, topic1, topic2, author1, author2 and Germany would be wikilinks. Although I’m not sure if that’d be correct syntax (should it be double brackets?).

A downside of this is that it doesn’t allow inline typed links.

2 Likes