Graph Link Types

[Feralflora]

This is really groundbreaking, I think. And it will fit into many people’s existing metadata / workflows easily, which is a big bonus.

[QuantumNeurotechno]

I’ve really wanted something like this for a long time, thanks for making this!

[Mutzu]

I really like the idea!

As some feedback I’d like to say that sometimes I want to use properties that shouldn’t show up as a graph link type text.

I have this suggestion to change the syntax a little:

---
property A: [[Research Document 1]]::related
property B: [[Research Document 2]]
---

In the same way, you could use this inline:

[[Research Document 1]]::related

Or, if you want to add blanks, you could write:

[[Felicitas]]::married to::

[Mutzu]

If you want to add some stylization to the connections, this syntax could be handy:

[[Research Document]]::relate | thickness | color | attraction::

thickness is a value ranging from 1 to 100.
color is either a 6 digit hex number like FF5533 for a RGB color value, or a 8 digit hex number like 335522AB for a RGBA (Red, Green, Blue, Alpha/Transparency, ) color value. I omitted the usual #, since this would collide with the hashtag syntax.
attraction is a value ranging from -100 to 100. 0 means nothing changes with the distance of the connected nodes. 100 means maximum attraction between the nodes. -100 means maximum distance between the nodes.

thickness, color and attraction could be omitted from right to left.

Then you could insert the value of a property in the connection data, for example to affect the thickness of the line:

---
Oxytocin.increment: 15
---

Some text...

[[Serotonin]]::increases | 26::
[[Oxytocin]]::increases | {{Oxytocin.increment}}::

In a CSS file, you could specify how many pixels would correspond to a thickness value of 100.
And also how many pixels would ideally be the distance between nodes with an attraction value of -100 and 100, with no other forces applied.

Since I don’t have the time to contribute to GitHub, I just write my ideas here in the comments.

[natefrisch01]

Wonderful thoughts. I’m just rewriting some of this so it’ll be clear to me if we implement this.

<MetadataTag>:: [[Research Document 1]]<GLT marker><DisplayName> | <Thickness> | <Color> | <Attraction>

I think we should use something besides :: for <GLT marker>, because in the inline notation I’m not sure what Dataview would do with it. could perhaps be |, ->, GLT, etc. or some combination of them. Also, by default I think it should still use <MetadataTag> as the display name, but make it an option in our list of tags to change it or make it nothing. Also, we should use identifiers so that you don’t have to include all the options if you don’t want to. I.e.
<DisplayName> could be DisplayName, "related" or DisplayName, ""

Some examples, assuming <GLT marker> is |:

property A:: [[Research Document 1]] | DisplayName, "related" | Thickness, 100 |
property B:: [[Research Document 2]] | DisplayName, "" | Color, FF5533 |
property C:: [[Research Document 2]] | Attraction, -93 |

Modification we’d have to make:
extractPathFromMarkdownLink() and extractPathFromWikiLink() should return, in addition to paths, all the arguments as a dict or something. Then those would argments would be returned from getMetadataKeyForLink() and used in createTextForLink() to implement the optional arguments.

These are some great ideas, thanks for taking the time to work out potential syntax for these features!

[Mutzu]

Thanks, cool.

Yes, I agree with your points.

I think -> would make the most sense aesthetically and intuitively for the inline notation.

[[Research Document]]->relate|70|

To make DisplayName nothing inline you could write:

[[Research Document]]->|70|

Sometimes I make a graph visualization where I need to have more than one connection between two nodes. Transparency could show this, but the connection labels should not overlap… Perhaps the DisplayNames could be separated with a / in the graph view?

If two notes have more than one connection, I think the applied attraction in the Graph View should be the average of the attraction values of both notes.

---

When I have some time, I’d like to try to implement my idea to display folders in the graph view:

Show folders as areas in the graph

I was thinking about the Venn diagram dilemma that would happen when trying to visualize all notes and tags within folders. The solution could actually be quite simple: You leave the tags outside the folder areas. This would give them a graphical interface function. The following rules should suffice to customize the Graph View in this respect: Add a force that attracts notes from the same subfolder Add a force that repels tags from the folder scope Ensure that a subfolder stays within its …

Is there a way to access the graph view from a plugin? I didn’t find it in the documentation…

[Mutzu]

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.

[natefrisch01]

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.

[Mutzu]

Thanks! 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.

[natefrisch01]

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.

[Mutzu]

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…

[Mutzu]

I suggested this as a feature request:

Graph View Wrapper for Plugins

Use case or problem I would like to add some features to the Graph View, but unfortunately there are only a limited number of ways to do this. https://forum.obsidian.md/t/show-folders-as-areas-in-the-graph/8208/13?u=mutzu Proposed solution I read that the internals of the graph view are a bit convoluted. Maybe you could just provide something like a wrapper with simple methods? Then you wouldn’t have to reorganize the code if you don’t want to… It might look something like this: GraphView.No…

[NarraAtor]

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

[Felixius]

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.

[Felixius]

Yeah, me too

[Feralflora]

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

[Felixius]

Thankyou

[natefrisch01]

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]

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]

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?