It has been around 6 months since this post was first made… is there any workaround as of yet for implementing this functionality?

This way of adding types to links seems the simplest way:

Is there any plugin that implements this or anything similar?

1 Like

try breadcrumbs. It’s great

1 Like

Link is the big feature that lead me into using obsidian, just because linking knowledge and having backlinks as a first class citizen easily connect things. I was totally sold on the graph view !

However as the number of notes i have grows with the number of meetings, projects, people, organizations and technologies i take notes on, the global graph itself became very cluttered, and even the local graph became quite difficult to sort out. Adding colors to nodes did the trick for some time but i fear that graph views quickly becomes just nice for screenshots but not actually very exploitable.

The main reason for the graph view to quickly reach its limit is that instead of being a canvas where i can organise notes spcially myself and that view get saved it is laid out automatically. And there is no way to lay out the notes in any smart way automatically because all notes and links just have the meaning of “linked to”.

Linking two notes to an intermediary note just completely loose the benefit of direct linking and is more like the work around that non graph database uses as “join table”, it will clutter the graph view even more.

I think the key feature in obsidian being the links, the product should embrace everything that makes the success of graph database. Links should be typed so that rich semantic queries can be achieved in the search. Optionally in the future they could hold parameters or link to their own note or a note could describe the link type. But semantic linking seems to me the single most important thing to begin with.

And no matter what theory says about what kind of links should exist between notes, obsidian is built on the concept that people decide their own workflows, so for me what kind of meaning the links have is something that must be left for the user to decide, for example between a #project note and #person note, i could have several link, one linked as project lead, one linked as analyst, or more general links like works on, works for to link organsations, implement link for a product linking to a research topic.

This product : https://heptabase.com/ implements the graph view as an actionnable view that instead of being automatically laid out are infinite views the user can add the notes and organize them spacially into, it also has some typed link supports. Such a kind of user-organized view allows to make timeline or even kanban without any need of plugin support, just by user’s own visual conventions.

Those are the two linked topic i would love to see obsidian move to : semantic links and the ability to not just save the graph view but make it my own canvas where i can layout (and see!) my notes inside, saving dashboards for later use.

2 Likes

Thank you so much for suggesting breadcrumbs plugin :smiley: … I would have completely overlooked breadcrumbs if it weren’t for your comment. i had taken a look at it initially but it had seemed it was only for a parent-child like hierarchy … but i had a look at its wiki page again after your comment … and it is almost exactly what i wanted when combined with dataview inline syntax and juggl plugin.

1 Like

haha no worry. It was me that overlooked it at first. We are the same :joy:

1 Like

It sounds like you want to look at the Excalidraw plugin? The author is very enthusiastic with it; he has a lot of video tutorial and examples.

1 Like

Because I think if something that big comes into obsidian it has to be a core feature, a whole new kind of object supported natively. There is a lot you can add with plugins and community but what’s in the core shows the drive direction the product is taking and what they will ultimately support and build into the core engine.

Excalidraw is fantastic, but yet it’s a kind of embeddable object that you edit externally, i feel like adding handwritten doodles to notes should be part of the feature set of an editor (just like adding pictures or text) and not provided by a particular plugin. What i mean by that is that I think it should be a core feature expandable by plugins, and not a plugin that won’t benefit from every other plugins nor from the default feature set.

Supporting native obsidian links from inside excalidraw/kanban will always be a bit cluncly, because as much as developpers will have to try to make it look like obsidian content, they can’t rely on default styling, default tools, user plugins… just because whatever content you add there is not inside the default editor. It’s a lot of work just to recreate what can look like you are authoring a regular obisidian content but it’s not.

Perhaps the solution for better content plugins is to have a fully embeddable working note editor so that even in the case of kanban/excalidraw you can view and edit all the notes without leaving that view, and the obisdian editor to be made “embedding-aware” in a sense that plugin could resize it, limit the content of what’s displayed in the note or adapt the font if the editor is getting too small.

The main difference between core functionality and plugin is that core functionality show a commitment to a design decision, and then plugins can further enrich that experience with more nice customization. Whereas a plugin offer a functonality but won’t benefit from any other plugins enrichment beside what you can choose in the plugin options and the developper itself is willing to add. That’s why the big stuff need to be core and part of the plugin API for people to do creative things with them :wink:

There is a good reason why kanban and excalidraw plugin have such a limited syntax support in the link/content they support : they need to re-code all that obisidian logic by hand.

1 Like

Thanks, I used this to write hierarchies for breadcrumbs plugin.
Eg. One of hierarchies is: supports (parent ) , supported by (child) , refutes(next), refuted_by(prev)