Add support for link types

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%

image

3 Likes

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.

2 Likes

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.

4 Likes

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.

6 Likes

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.

Lastly:

- this list
- should have
- a third custom class
{.baz}

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!

4 Likes

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.

3 Likes

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.

4 Likes

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

image

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?

2 Likes

Howdy,

Having started with the Zettlekasten Method and learning how links within that method are created (which fit with the existing Obsidian functionality), I started wondering about how to extend those links with additional semantics based on Mark Burgess’ four meta-types of semantic links with four directions each.

Within the context of Mark Burgess’ ideas of Semantic Spacetime there exist four meta-types of semantic links that ought to improve our ability to model information. These are:

  • CONTAINS (where A contains B) - a container/space-like relationship
  • FOLLOWS (where A follows B) - a sequential/time-like relationship
  • EXPRESSES (where A expresses B) - a local property being expressed
  • NEAR (where A is near B) - a similarity/nearness relationship

Each one of these types can be expressed in four directions:

  • Forward : ex, “Contains”
  • Backward : ex, “Is Contained By”
  • Negative-Forward : ex, “Does Not Contain”
  • Negative-Backward : ex, “Is Not Contained By”

Lastly, each one of these meta-types can be instantiated by a specific type. For example FOLLOWS can be a relationship between events in time, assertions in an argument, process outcomes, etc.

So, the link type I would like to be able to express has three attributes:

  1. meta-type: one of Contains, Follows, Expresses, Near
  2. direction: one of Forward, Backward, Negative-Forward, Negative-Backward
  3. type: the specific type (not meta-type) of the link: “Is Like” (Near), “After” (Follows), “Depends On” (Contains), etc.
8 Likes

Use case or problem

I’m trying to make a concept map like described here: Concept map - Wikipedia

Proposed solution

Adding the abillity to add relations (like here: Concept map - Wikipedia) between obsidian notes (concepts/ terms/ definitions)

Current workaround (optional)

no workaround

Related feature requests (optional)

nope

no workaround

Have you checked Juggl plugin?

1 Like

You could also try to create a separate note per concept and then have notes that reference that concept note? Could also have the concept as its own tag which will also show up in graph-view.

1 Like

Support Roger Shank’s learning structure (Engines for Education) that provides additional meaning in the structural links themselves

Each note supports four new categories of links

  1. What led to this?
  2. What does this lead to?
  3. Where is more detail?
  4. What is the context for this?

The user need to be able to define what kind of link, and edit the category type. User then can enter a structure anywhere by text sech, quickly navigate to the knowledge being sought

4 Likes

He had three other categories some people use, Give me examples, Give me alternatives, and What to avoid.

That’s an interesting approach. Seems very useful for a complete system.

Probably it could be a bit complex to start with. Perhaps we could start with a more functional approach in the sense of: Which different link types are used most often?

Here a suggestion for the situation: In note A, there’s a link to note B. (the categories “(in)direct links” indicate the “weight” or “order” of the link; the initial symbol could indicate a graphical represantion of the semantics of the corresponding link):

  • direct links (first order links or greater weight links):
    • ⇒: B is the logical consequence of A.
    • →: B is an argument following A, i.e. the “next step” in an argumentation
    • ↔: B is the opposite or the/a critique of A.
  • indirect links (second order links or lower weight links):
    • :arrow_upper_right:: B is another topic that is related to A (“cross reference”).
    • ↑: “external” link, i.e. link to a file, a website, or another type of note (e.g. an literature excerpt).

This would reduce the number of possible link types.

4 Likes