Add support for link types

The whole advantage of Markdown is that it is human and machine readable.
We can read and understand it easily in Preview mode and Edit mode.

The more complicated we make Markdown in Obsidian, the less readable it is in edit mode.

If we’re going to add link types in Obsidian, I think the answer lies in the YAML header and not in the notes because:

  1. That way we only see metadata when we’re trying to look at metadata
  2. Hides complicated syntax from novice users
  3. It just looks cleaner and easier to read.

I quite like the double-colon syntax. Another place that syntax is used is in Gitlab to distinguish between components in a label.

1 Like

Fair points @DandyLyons

1 Like

Currently, Remnote had relationship name/connection name / edge label in graph view.


like this one in Neo4j.

Use case or problem

As you can see here the data model consists of Nodes and Relationships. And both nodes and relationships will have properties associated with them. And together all of them will make a data model which will give us the better visual understanding of a dataset.

Properties are information associated to nodes. For example, if Wikipedia were one of the nodes, it might be tied to properties such as website, reference material, or words that starts with the letter w, depending on which aspects of Wikipedia are germane to a given database.

Labeled-property graph
A labeled-property graph model is represented by a set of nodes, relationships, properties, and labels. Both nodes of data and their relationships are named and can store properties represented by key/value pairs. Nodes can be labelled to be grouped. The edges representing the relationships have two qualities: they always have a start node and an end node, and are directed;[10] making the graph a directed graph. Relationships can also have properties. This is useful in providing additional metadata and semantics to relationships of the nodes.Direct storage of relationships allows a constant-time traversal.

Hope Obsidian have a way to implement it.


I wish markdown had something to embed ‘invisible’ metadata.

How about Open Graph Protocol?

  1. It’s “invisible”. Its just an HTML tag which will be invisible in Preview mode.
  2. It’s already an established standard with documentation.
  3. Fairly simple to write, read, and edit.
  4. It’s widely used across the internet (which means we may even be able to automatically import metadata by simply pasting in a URL into Obsidian): Automatically fetch and import metadata using Open Graph Protocol -> YAML Metadata

These are interesting points. Currently, for Neo4j Graph View, I’m having both a list of typed links like - hasTopic [[note]], and like @msteffens mentioned, I’m thinking of adding the double-colon syntax.

What could be changed here is to move or also allow the list of typed links within YAML frontmatter. Personally, I like seeing them rendered, though. The double-colon syntax would also be completely optional, so complicated syntax is hidden from novice users.

Furthermore, I think an inline syntax like double-colon is important! This is because it’s much more natural to write linearly. If you mention some fact in your text that you want to annotate, it wouldn’t be natural to move to the frontmatter to add this fact in the typed link syntax another time.

1 Like

Hi @Steve what is Remnote?, is it opensource? (curious)

I’ll add link to original post. I thought every obsidian user know remnote.

I’ve just tried it, but I cannot find the graph you presented.

There is also syntax for adding metadata to any markdown element used already in many implementations.
Request for official inclusion in Commonmark is here:

I might post request to recognize this markdown extension here on Obsidian.

Another inspiration from RemNote: Display vertical context in long scrollable document (RemNote-like auto-folding mode)

Is it possible in Neo4J/Cypher for link/relation to be subject or object of another relation?
For Example:

([[A]] requires [[B]].)  implies  ([[A]] is member of [[set C]].) .

Could we use something like attributes with the “::” syntax (like Roam has) to help specify link relationships?

1 Like

For folks interested in the topic…this article might be interesting:

1 Like

This is a really well designed graph format!.. thanks!

The last code-block in the article about the Gram makes it confusing / does not make sense to me.
(c {when:date`2021-01-21`})
should refer to
instead of

If it is possible to refer the link as <-[c:Read]-, then it is more useful.
Can anybody contact the author of the article - Andreas Kollegger? I do not have Twitter or GitHub account. @akollegger

Another medium article on Gram

Your observation makes sense to me.
You might imagine assigning a property such as birth date to node c. e.g. (c:Person {born:‘2021-01-21’}), but agree that the date property for when read makes more sense on the [: Read] relationship than the (c: Person) node.

For what it is worth, Gram seems to come from the “Cypher” query language of Neo4j and cypher allows typed properties for both nodes and relationships.

@Emile is a bit of an expert with neo4j and may have a perspective…

I found this thread as I’m in the process of restructuring my vault to better expose the relationship between pages, e.g. if page is a variation, aggregation or contraction with another.

Work-around, not ideal: rather than linking directly in the page, I’ve rewritten my links as footnote reference, and then tagging the footnote itself with the relationship. In the example below, “AG” standands for “aggregation”.

The benefit of footnotes is that it allows for descriptions and elaboration of the relationship.


Interesting use of unicode! I’ve experimented with using symbols in a similar way, for example using one of the unicode bank branch codes to denote a branch from a line of thought, e.g. ⑆ [[link to branch]].

But so far I’m not needing that particular case, though I am using aggregations adopting the term “MOC” from Lion Kimbro & Nick Milo. I’m using unicode / emoji directly at the front of the note name for those.


  • ✧ mini-MOC
  • :sparkles: MOC

That helps at least distinguish them as aggregations, directly in the filename.

1 Like

Very nice!

For me (and this very much depends on the usage), the “page” and their “relationship” are distinct - e.g. my notes on “empiricism” is a statement of what empiricism is; and it may relate to other cards in different ways (e.g. something that “objectivism” builds upon).

A given page may have many relationships, e.g. an additional meaningful relationship for the topic of empiricism might be “conflict” (e.g. rationalism is at odds with empiricism).

This is all under the context of Leonard Peikoff’s statement that:

Human knowledge is not a mere collection, but a structure; it is a single body of interrelated cognitions. No item of knowledge is “self-contained”; taken as isolated from all the rest, no item even qualifies as knowledge. On the contrary, such an item, being closed to potentially relevant evidence, is a form of unreason, and as such must be rejected. This rejection does not mean a condemnation of cognitive specialization. What the theory condemns is any specialist who claims a logical right to ignore discoveries in all fields but his own, on the grounds that his exists in a cognitive vacuum and is thus self-validating. Ayn Rand called such individuals “compartmentalizers,” and often cited as examples pro-capitalist economists who regard morality as irrelevant to economics.

It boils down to: what do you want your vault to be?

  1. Exposing the relationships between statements, to help spot patterns (conceptualise/abstract) so you can create new ideas (integrate/synthesise) - this incurs overhead in integrating new pages;

  2. Be a dictionary where you declare a page is a type-of something. You can leverage (the awesome) full-indexing in obsidian to quickly retrieve things - however reading a dictionary is a hard way of learning a language.