Graph Link Types

Share & showcase
11

A compressed notation might look like this:

[[Research Document]]->|||90|
  • DisplayName is set to nothing
  • Thickness gets its default value
  • Color gets its default value
  • Attraction is set to 90

You could define default values for the parameters of a DisplayName in the CSS file. If you omit a parameter in the graph link type parameter list, it would be set to its default value.

[[Research Document]]->supports|20||30|
  • DisplayName is set to “supports”
  • Thickness is set to 20
  • Color is set to the default color for the “supports” DisplayName from the CSS file
  • Attraction is set to 30

I think it is a bit difficult to see the affiliation of a DisplayName to a link in the graph view when a lot is displayed, since every text has the same appearance.

Therefore I suggest to write the DisplayNames of the graph type links in italics to make them more distinguishable from the node labels.

1 Like
12

Another great idea for showing multiple link types in one file that point to the same file. I made a feature request that I think captures what you’d want.

1 Like
13

Thanks! :pray: For the properties block, I’d suggest this approach if you want to have relate as the shown DisplayName:

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

If you want to set DisplayName to nothing, it could be:

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

Then this would look the same way as in the inline notation for no displayed name.

1 Like
14

Displaying folders as a shaded area in the graph view would be awesome! “Is there a way to access the graph view from a plugin? I didn’t find it in the documentation…” Well, there is not much support by obsidian for accessing the graph view in plugins, and from what I gather, it is low on their priority list to make an API to access it. I think this is because it’s internally complicated. That being said, with enough patience, I was able to put together a manageable solution:

  1. Access the Pixi.js renderer for the graph view. findRenderer()
  2. Add children (extra things you want to draw, in my case text, in yours the shaded area) to the renderer. In createTextForLink() see renderer.px.stage.addChild(text).
  3. Transform the position of the object you created to match the coordinate system that obsidian uses. updateTextPosition()

What this means is, I think adding area shading for folders would be doable! The more difficult part, in my opinion, is figuring out how to group the nodes and writing their position, but again, I think this is doable. To do this, you need to edit the position of nodes that already exist, which to my knowledge, is pretty much the only thing we DO have access to thanks to (persistent-graph)[https://github.com/Sanqui/obsidian-persistent-graph/blob/master/main.ts]. See their restoreGraphData() function for how to do this. If anyone does know how to edit other existing objects, that would be incredibly helpful in adding new features to Graph Link Types as well, since we wouldn’t have to be drawing new objects over exisiting ones.

1 Like
15

If the internals of the graph view are that convoluted, maybe they could provide something like a wrapper with simple methods? Then they wouldn’t have to reorganize the code until they decide to do so…

1 Like
16

I suggested this as a feature request:

3 Likes
17

Hello there! This seems lovely and I want to use it but I can’t find you in the community plugins. How can I install this? I also tried searching your name but that didn’t work either :confused:

image
image1231×854 7.06 KB

1 Like
18

Oh wow, I was just thinking last night that I could really use something like this in Obsidian and it was one of the capabilities I missed since switching from thebrain.

1 Like
19

Yeah, me too

20

& @NarraAtor Use the BRAT plugin to install it, since this is still a beta plugin.

2 Likes
21

Thankyou

22

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!

1 Like
23

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 :muscle:

2 Likes
24

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?

1 Like
25

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

1 Like
26

I did some improvements, at least I think so :slight_smile:, 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)…

1 Like
27

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:

image
image1920×1034 122 KB

1 Like
29

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')
1 Like
30

Looks good! :slight_smile: 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++.

1 Like
31

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

image
image673×772 26.9 KB

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.

6 Likes