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?
try breadcrumbs. It’s great
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.
Thank you so much for suggesting breadcrumbs plugin 
… 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.
haha no worry. It was me that overlooked it at first. We are the same 
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.
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 
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.
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)
I hadn’t come across this but, as someone who is soon to be starting a lot of information capture in Obsidian, it looks like it is well worth looking that as a methdology to use in that process. Thanks for posting it
+1
As a TheBrain user too, link types is something I dearly miss in Obsidian as well.
Any update on this topic? Links types sounds like a no brainer feature to me!
If at least there could be room for a syntax to let link type/properties be a thing then a plugin could use that new semantic. [[ ]] links have already been twisted to accept meta-data for images like size, or alias, so markdown “pollution” would be a bit of an hypocritical excuse.
I find it sad that this link as a first class citizen claim lead to something even less expressive than simple html hyperlinks in the end, a lot of how my notes are linked is to be expressed on the link itself and not on the source or target page, and there is no workaround this, knowledge is a graph, and a graph datamodel is the superior paradigm. I’ll migrate all my notes to the first PKM software to support link types/annotations, even more so if it can be enriched by properties…
I’m totally willing to wait if this appears on the “long term” roadmap, but with no sign at all that this fit or fit not the long term vision of obsidian and no visibility at all on that trello as to the direction that the products want to take i don’t see myself supporting another year 
How do you imagine writing the link types?
First, I think the utility of something should be established independently of “how it is best implemented”. Having made my case as to why i would consider it useful, all I can do it some example proposal, none of which will be without impact or standard, because markdown was never made to offer semantic or parsability, it was just design to be cosmetically similar to a styled text while not imparing readability ^^
Proposes a :: syntax similar to the one we use in dataview and so would fit pretty well into what already exists. Probably the read view could hide that prefix part also as it’s not necessarily mean’t to be read but there to improve search, graph or give dataview a whole new set of rich queries.
Obsidian itself has a whole lot of ways to add stuff not originally envisionned in the markdown spec where it’s lacking, like the #page=number that works with PDF document, the [[image | 100x100]] size parameter that only works with images or can be used as alias… there could be optionally more parameters following that would simply not appear at first and could be implemented later or already used by plugins, if there was just somewhere to write them. It can also be some prefix to the link : works_for::[[link]] that doesn’t necessarily appear in the rendered view.
If non standard syntax could be added to a PKM tool for aligning an image, opening a PDF to the right page or introducing an alias, it would be sad to refuse to add syntax for something that is fundamentally PKM related.
Some months ago I wrote a prototype to have link types.
The syntax is a variant of what MediaWiki uses, which is very simple. I call this syntax dot-triples
It consists of phrases of two or three tokens.
If I write a phrase with three tokens, for example:
[[Bob]] :: is a :: [[Person]]
then a triple is generated.
If the phrase has only two tokens, then a triple is generated, but the subject is assumed to be the current note.
date created :: 2021-12-22
will be equivalent to
__THIS__ :: date created :: 2021-12-22
This allows me to have typed relations.
One can also write phrases that generate more triples.
[[Bob]] :: wrote about :: [[Topic 1] and [[Topic 2]] today
The plugin reads the triples and indexes them in a Database (Triplestore) each time I save the file, which I can later query using a language called SPARQL.
Edit view
Normal View
Looks very interesting! 
That is super interresting !
I’m in need to express those more strucuted relationships between objects, and this at the same time has the added benefit to not get in the way of readability and natural writing.
Do you use some kind of in-memory graph db for the model and querying ?
I use an external database, an RDF triplestore. However, I think there are implementations that work in memory, that for small vaults would be enough.
What do you mean?
