I would use the reasoning to infer relationships between entities I linked. Where is_parent would link back with is_child. Hence the goal to use formal ontologies, rather than thesauri. To enhance the PKG with more explicit linkage.
Obviously, only for front matter, for otherwise inline links would be a pain to reason over (I think).
But what about the inline variables that DataView uses? or another thing?
I want to do the same, reasoning, not only for the front matter. I recently wrote: GitHub - cristianvasquez/docs-and-graphs: Parse markdown into a simplified Abstract Syntax tree that extracts inline variables; I want to use them to generate RDF or Datalog to reason.
I think this is actually the best functionality for implement some kind of typed linking in Obsidian, indeed, and now i’m using it.
There are plugins that use them, such Excalibrain.
I think that if standard Obsidian graph would implement features like Excalibrain, it would become a killer feature
Please forgive if my contribution does not fit well, I am a recent user.
I would really like typed-links that would work for all type of links, and especially block links.
Blocks are not yet first class objects , hence plugins do not usually provide block-level functionality, only note-level (e.g. ability to retrieve just the block that inlines a dataview variable would be great for me).
I’m not certain if this is what you mean, but you can link directly to blocks, and also embed a single block using Obsidian.
More info here: Internal links - Obsidian Help
Although true, you can use block and section (header) links to reference in other notes, what is missing is any metadata about that link (particularly transclusions), a title for example. When using wikilinks format, the display text does not render. Our developers are aware if this. This topic (link types) would go far in addressing this issue, but full “first class” is not an easy thing to implement for a variety of reasons.
A proposal for rendering block embeds inline - #84 by writtenfool
+1 for the whole discussion.
Also, i would greatly appreciate the ability to customize the way different class of links show in graph view, like dotted/dotted line arrows, different colors, labels on the edges, invisible links. And it would be great to customise specific link on-the-fly without writing a specific class for a single link, like i did below.
My proposed non-invasive into the wikilinks notation type linking would be adding a json-like array of options, like: Ann [[Bob|likes Bob]]{color: "#00ff00", label: "likes", type: "--"} in the Ann.md for the dotted line green link with label “likes” between Ann and Bob. Or, as suggested above, something like Ann [[Bob::likes::|likes Bob]] where the ‘likes’ class specifications is stored somewhere in the options (maybe the same way as the json example).
I really looking forward to using this feature when/if it’s added.
Is there any way to add a link without creating a link in the graph? Like, some kind of surface level link that simply points to another note without muddying up the whole thing? There are many things I’d like to link but don’t necessarily want the notes showing up in the graph because of it.
I don’t think so. You could reference the name of the note without making a link to it—i.e., create the link and then remove the double-brackets surrounding the text. You’d then at least be able to refer manually to it. A sort of manual/mental link, if you will.
Obsidian URL links won’t make a graph connection.
Brilliant. Thank you.
you can write your note inside an Admonition block (Admonition is a community plugin). The note you link is not added to your backlinks
Trillium Notes balances this nicely (link : Relation map · zadam/trilium Wiki · GitHub).
They separate the concept of links (just like any wiki / obsidian) and relation. Relation are expressed as promoted attributes (think about it as page level attributes like front-matter has) but accepting other pages as value, the thing that for syntax reason seems to raise so much debate in this community.
Those promoted attributes are used to create a page graph with named relations, useful in search, visual thinking, and uncluttered by too many simple links appearing in the course of a long page. That dichotomy of having simple anonymous links in the page like any wiki and more important named relations between the pages gives two layers of representation/search.
And again all it would take to achieve this is official link support in the front-matter, and by that I mean links that also get updated when the target note gets renamed just like any other link does.
The next level would of course being able to add properties on the relation itself (e.g. a relation between a project page and a person page with label “works on” could have properties reflecting the start and end date of that assignment as well as the role assuemed by person on that specific project).
Wow that’s really interesting, I hope the obsidian devs take a look at this
See also the tiddlywiki map
It has automatic relationship view as well as manual relationship view like obsidian leaflet.
Another hot app at the moment that is more Notion-like is Tana which support what they call supertags (Supertags - Tana Help Center). Basically tags allow key-values pair relevant to the tag (e.g. a Book tag can bring author and publisher properties), and values can be typed, this allows value to be simple constants or types as other type of notes.
It’s an interresting take to have attirbutes attached to tags and then tags attached to notes as it allows notes to bear several tags hence to be of several types as once, and as such to appear in multiple view and to hold attributes coming from all their tags.
I feel this offers both the meta-datas and typed relations in a very nice way.
You can in fact create a “supertag”-like structure in Obsidian by using the “Metadata-Menu” plugin. There is even a Video on youtube where it is explained, how … LOOK!
Also waiting for support of link types. 
+1 for link types!
Would be a great feature. especially if one can filter the graph view based on link types.
To push it further, the syntax could be something like [[Berlin]]{type: capital}, which would allow to attach any metadata to the link, not just a type.
