Add support for link types

[lysergico]

Brilliant. Thank you.

[gkionism]

you can write your note inside an Admonition block (Admonition is a community plugin). The note you link is not added to your backlinks

[tobei]

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

[lysergico]

Wow that’s really interesting, I hope the obsidian devs take a look at this

[KuiyueRO]

See also the tiddlywiki map

It has automatic relationship view as well as manual relationship view like obsidian leaflet.

[tobei]

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.

[jmbarkei]

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!

[pt3]

Also waiting for support of link types.

[minimamoralia]

+1 for link types!

[tgirod]

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.

[bojangles]

As someone who utilizes the graph view a lot for visualising the relationships between my notes, I would absolutely love this!

Even just something simple like being able to specify different coloured lines for different types of links would be so good since most of my notes resemble different ‘ideas’ and the links are how they are related.

I would probably utilize it by doing like the default colour for positive relationships (“these two ideas are related/depend on each other some way”), yellow for comparisons (“this is similar to this idea”), and red for negative relationships (“this idea is the opposite of this other idea”)

[NickWrightData]

I would LOVE this feature. Has anyone developed it as a community plugin?

[ironicplaid]

+1 for link types. I really need this functionality.

[bojangles]

Another idea with link types is to additionally have link weights, where stronger links (e.g. 1.0) get a multiplier to their link force on the graph view to make them appear closer together, while weaker links (e.g. 0.2) might have a negative multiplier.

The idea here is you could differentiate something that is extremely closely related vs something more tangential by just looking at the graph. This way, you could make “clusters” of closely-related information and have external links to other clusters. I would be really excited to see something like this.

[tobei]

I we are to add “weights”, i would prefer to generalize the idea that links between notes can have attributes/properties (like in all graph databases). This makes it easy for example to link a project and a person note with a role name, collaboration dates etc. That would be an important step toward the “link as first class citizen” paradigm

[writtenfool]

@AtrusRiven

Here a suggestion for the situation: In note A, there’s a link to note B. (the categories “(in)direct links” indicate the “weight” or “order” of the link; the initial symbol could indicate a graphical represantion of the semantics of the corresponding link):

• direct links (first order links or greater weight links):
  • ⇒: B is the logical consequence of A.
  • →: B is an argument following A, i.e. the “next step” in an argumentation
  • ↔: B is the opposite or the/a critique of A.
• indirect links (second order links or lower weight links):
  • : B is another topic that is related to A (“cross reference”).
  • ↑: “external” link, i.e. link to a file, a website, or another type of note (e.g. an literature excerpt).

I like the concept of assigning weights, the direct method would force me to think and describe the weight (subjective). Indirect pulls from somewhere else and involves a “third party” weighting.

For some contexts, a simple argument type is perfect (contradicts, supports, expands on, etc).

But for more complex relationships and topics, the type varies from my subjective weight to more semantic weighting based on the words, phrases, concepts shared between the two notes.

Can you folks elaborate more about assigning a “weight” from your perspective.

Boiling this conversation down into a design for development will be a challenge

At a basic level for most users and uses a simple argument link type is sufficient but for more complex analysis there would have to be a whole collection of methods and related meta data; especially if notes are atomic.

[bojangles]

Hmm, the simple argument is also a really good idea, though I think not all of the links will always be used and some people might want their own link types.

I think the best solution might be to have templates. Where you could have words that are associated with each weighting, which also lets users create their own link types and/or adjust the attributes of the other link types.

Additionally, perhaps another point of discussion would be whether to make the links:

• conversational
  • e.g. Within an “Agonist Drugs” note, you have “[[[contradicts|0.5,red]]] [[Antagonist Drugs]]” which links to the note. I used ‘[[[’ and ‘]]]’ to designate the link but something else could be used
• or more embedded within the link
  • e.g. you have “contradicts [[Antagonist Drugs||0.5,red]]” (I just used a ‘||’ to designate the link details but it could be something else)
  • this one is probably easier to implement but I suppose might be more tedious for the user when writing the link
  • to activate a template, I’m thinking that upon writing ‘||’ it would suggest some templates and then the user selects the one they want (‘contradicts’) and it puts in what they want, though this could feel a little slow or clunky to do since you need to select which template to do in a list.
    • Though, perhaps a better method is to intelligently look for keywords before the link itself and then auto-complete the corresponding link attributes when the user creates the link (and then the user can also customise this list of keywords so that, for example, writing the phrase ‘partially related’ will load the same template as ‘somewhat related’)

[tobei]

There is already a syntax that is used to add properties to links that is used for image width or link to a PDF specific page, so it could also be used for key-value associated with a link. I prefer a key-value system because not everyone will be interrested by colors or weights or a limited set of relation kind, I feel it’s important to offer flexibility there for people to have their own attribute.

[msteffens]

Yes, exactly. A generic key-value system would be great. Further above in this thread, I’ve advocated an inline syntax that supports multiple type elements per link (delimited by double colons) as well as key:value elements, e.g.:

[[based on::extends::LINK_ID]]
[[evidenced by::weight:10::LINK_ID]]

Here’s an example screenshot to further illustrate this (the link type colors come from a global definition to avoid repetition within the notes):

[writtenfool]

@bojangles - this resonates and it only took 178 responses for me to get here

In today’s parlance considering our upcoming database future, each link:

• is an object (just like a note)
• has properties (hopefully, just like a note)
• has inheritance (a parent note and its properties)
• has offspring (anywhere it is instantiated)
• is unique at each instantiation - so it has it’s own context ( @bojangles template )
• has time properties - created, modified (will they be static or dynamic?)
• has place properties - where created - a note in either a local vault or a published place
• has “who and how” properties - me or code creating or modifying it and by what manner and UI gesture
• can be reusable - a templated link, if you will

We have at least four players (objects) in the linking game: note, link, offspring, and place. Each has it’s own set of properties.

The game starts with creating a link in a local vault (instantiation). What would that UI gesture look like?