Graph Link Types

Felixius · February 9, 2024, 10:59pm

Thankyou

natefrisch01 · February 12, 2024, 5:57pm

It’s currently being reviewed by the obsidian dev team to be a plugin https://github.com/obsidianmd/obsidian-releases/pull/2914.

Presently, if you want to use it, you just have to copy the main.js and manifest.json file from https://github.com/natefrisch01/Graph-Link-Types/releases into a new vault folder:
.obsidian/plugins/graph-link-types/.

Or see @Feralflora’s comment.

I will post on this forum when it’s review is finished by the dev team. Thanks for your interest!

Lenny · February 15, 2024, 12:53pm

I think this is awesome and wanted something like this forever.
However the plugin GitHub - SkepticMystic/breadcrumbs: Add structured hierarchies to your Obsidian vault also offer some of these functionalities and much more (just lacking the visual part) and dev has recently re-started its development after a break (see the V4 branch).
It would be perfect if these two plugins joined forced together for solving a huge problem that Obsidian core will probably never solve

Mutzu · February 20, 2024, 3:30pm

Hi @natefrisch01,

I was thinking about my syntax suggestions…
If there is no Graph Link Type label and additional parameters in the properties block, it doesn’t look nice because it ends with ]]|.
Also, the placement of the -> in the line seems to me to point in the wrong direction.
So I rearranged the syntax:

A normal graph link type notation would look like this…

relate->[[Research Document]]| Thickness | Color | Attraction |

relate, Thickness, Color, and Attraction can be omitted, thus assigning their default values defined in the CSS. Each DisplayName could have a specific set of stylizations. Thickness, Color and Attraction can be omitted from right to left. Then there are only as many | as needed to separate them. If there is at least one of them, there is one | at the beginning of the parameter list and one at the end.

Of course, it would be possible to specify the parameters by name:

->[[Research Document]]| DisplayName, "related" | Thickness, 100 |

Edit:
Perhaps the , could be replaced by a : to match the key:value syntax. But I think it’s important to have | as a delimiter, because it’s much easier to read in combination with a :.

->[[Research Document]]| DisplayName: "related" | Thickness: 100 |

Here are some examples for the properties block at the beginning of a note:

---
relate->[[Research Document A]]
relate->[[Research Document B]]| 50 | FFCCBB | 20 |
->[[Research Document C]]| 70 |
---

The inline notation would look like:

"married to"->[[Felicitas]]
relate->[[Research Document D]]|| FF2311 |
relate->[[Research Document F]]| Color, EEBBCC | Attraction, 10 |

What do you think of this?

msteffens · February 21, 2024, 7:54am

Mutzu:

The inline notation would look like:
"married to"->[[Felicitas]]
relate->[[Research Document D]]|| FF2311 |
relate->[[Research Document F]]| Color, EEBBCC | Attraction, 10 |
What do you think of this?

Personally, your proposed syntax feels too busy for me to be used as an inline notation. And I think it would be beneficial if the link type notation would be part of the link itself, and not be placed outside of the link. Also, I’m not sure if link-specific color & thickness specifications are really needed. Personally, I’d want a semantically named link type (like “supports” or “refutes”) to always use the same visual appearance (e.g. thick green or red, respectively). Attraction (aka “weight”), however, seems useful and could be used to style the thickness property of the link’s edge/arrow.

Personally I’d prefer a key:value-style syntax inside the link (proposed here):

[[supports::LINK_ID]]
[[evidenced by::weight:10::LINK_ID]]

If really needed, this generic system could be also used to add key:value types like color:..., thickness:... & attraction:....

Mutzu · February 25, 2024, 3:41pm

I did some improvements, at least I think so , by aligning the syntax to the Cypher graph query language.

Without parameters it looks like before:

relate->[[Research Document]]

But with parameters it looks like this:

relate-{Thickness: 20, Color: FF3344, Attraction: 40}->[[Research Document]]

relate-{20,,40}->[[Research Document]]

-{Color: 6655DD}->[[Research Document]]

-{CustomParameter: 15.7}->[[Research Document]]

If parameters are omitted, they get their default values specified in the CSS-file for specific connection types (like “relate”).

I’ll try to specify it as parsing expression grammar (PEG)…

natefrisch01 · February 27, 2024, 12:14pm

Graph Link Types is now officially a community plugin!

https://obsidian.md/plugins?id=graph-link-types

Install it from within Obsidian by using the Community Plugins: Browse button:

natefrisch01 · February 27, 2024, 12:51pm

It would be good to make the syntax less busy. However, the way this plugin is designed, the link format cannot be modified, because Obsidian’s base code is doing all the work for handling links. Thanks for the thoughts!

@Mutzu Using your last message, I worked on it a bit to make it look more like a standard call.
Perhaps it could look like this:

Proposed Optional Parameter Syntax

Syntax for defining links with optional and named parameters:

<link type name>::(target, [positional_parameters], [keyword_parameters])

Target Specification:

The first parameter is always the target and is required. It defines the link’s destination and should be provided in a format like [[Target Name]].

Positional Parameters:

After the target, you can provide positional parameters in a predefined order.
Common parameters include Thickness (integer), Color (hexadecimal string), and Attraction (integer).
For example, after the target: 20 (Thickness), 'FF3344' (Color), 40 (Attraction).

Keyword Parameters:

You can specify any number of keyword parameters after the positional ones.
These are provided in the format parameter_name=value.
You can use keywords for clarity or when the order is not followed.
A special keyword link_type can override the default link type name.
Other common keywords include CustomParameter for any additional settings.

Examples:

Basic usage with target as the first positional parameter:
```
links::([[Research Document]], 20, 'FF3344', 40)
```

Using a mix of positional and keyword arguments:

related::([[Research Document]], 20, attraction=40)

Specifying only a color with keyword argument:

connects::([[Note about an Idea]], color='6655DD')

Overriding the link type name:

relates::([[Some Theorem]], link_type_name='implies')

Mutzu · February 27, 2024, 7:23pm

Looks good! Thank you for incorporating my parameter ideas!

I like that target is nearby the link type name.

If there are no parameters added, I think the () around the target may be omitted. Probably that’s the most common use case if default parameters would be specified in a CSS file or within the plugin’s settings.

I am wavering between :: and -> which variant would be better.

I think -> communicates better it’s function, but then it collides with Cypher where the parameters within () belong to the target. And I like C++.

natefrisch01 · March 18, 2024, 3:27pm

The latest release of Graph Link Types now includes the option to color based on type!

2024-03-1811-06-26-ezgif com-video-to-gif-converter

Should customization of colors should be high priority? I’m trying to decide what to tackle next.

crav3r · April 1, 2024, 4:39am

Thank you for making a good plugin.
This is a function that I wanted.
But, it dosen’t work with notes using property, because property uses “—” as a a separator. I hope you solve this problem.

Flexit · April 1, 2024, 12:07pm

Many thanks from me too!

What to tackle next? From my perspective just allow some special characters in the description, specially arrows or “<” and “>”

Ixo · May 1, 2024, 3:28pm

Was looking to see if something like this was possible and immediately ran into your plugin, worked perfectly on my existing metadata with links which was nice.

I have a couple of comments for things that mess with the experience a little.

The text labels also don’t fade out when zooming out, they stick around but very small. (fixed this for myself by turning off the labels in settings, so not a huge deal)
When mousing over a different node the link colours on other nodes stay bold and highlighted as opposed to slightly fading.

Looking forward to seeing where you decide to take it from here.

natefrisch01 · May 5, 2024, 4:23pm

I didn’t realize this would be such a requested feature, so thanks for sharing! I’ll see if I can get it up today… I just need to find someway to access obsidian’s variable for opacity, and it shouldn’t be too much work.

natefrisch01 · May 5, 2024, 4:25pm

On github there are several issues related to the special characters, and I’m thinking I’ll need to handle a lot of special cases. If you were to copy and paste these issues in https://github.com/natefrisch01/Graph-Link-Types/issues/7 I’ll have a better chance of remembering when I overall this part of the code. Thanks for your help in finding these bugs and taking the time to let us know!

z2rec · May 6, 2024, 2:42pm

hey, I recently opened a feature request here looking to solve this issues of note sizes inside the graph and somebody linked this plugin as possible solution.

Although, this plugin does not fix my problem as of now, is this feature something you might look into and possibly implement in future?

komiksam · May 7, 2024, 11:16am

Woooow, I was looking exactly for this a while ago, amazing, thank you so much!