Add support for link types

Have a look at the new Juggl Plugin (features and further documentation here): it already provides basic functionality for this and as far as I understand the further elaboration of this feature is one of the most important topics on its roadmap!

2 Likes

Thanks for the link! :+1:t2:

I’ll definitely get some use out of that plugin, as I love the idea of graph workspaces. But I’d still like to see “Link Types” supported natively.

It seems too fundamental as a feature to be excluded from an app where links are meant to be first-class. Plus, the native graph view is much faster and more enjoyable to use, at least for myself anyway.

Appreciate your response! :grin:

3 Likes

It is not trivial to agree in representations of ‘link types’, there are many ways to do so. Moreover, one could also want more complex things, such as attributes of the links themselves.

If you need to express more, how to do it without complicating things? I don’t know.

I personally experiment with this format:

<< family member of [[Jane Smith]]>> since ‘2010-03-15’ .

That Means ‘this’ has a relation ‘family member’ with [[Jane Smith]], and the relation has a date.

Or

<< [[chocolate recipe]] include [[eggs]] >> quantity ‘3’, kind ‘ingredient’ .

But would it be good for everyone? Probably not :slight_smile:

I think if we make use of the fences

```using_the_syntax_we_want

```

We don’t need to change standard markdown…

1 Like

That’s a good point. Different people will have different use cases and will want to approach it differently.

I suggested the [[Linked File::Link Type]] syntax because I felt that it fit Obsidian’s current style, similar to [[Linked File|Alternate Display Text]] and [[Linked File#Specific Header]]. But admittedly, I don’t know much about what is considered “standard” in Markdown.

That said, I wrote the above post as a separate feature request, before I was aware of this thread, and it got merged in by one of the moderators. So that’s why my suggestions were hyper-specific to my use case: Simple link groups that can be toggled in the graph view.

Maybe that’s just me being a minimalist :grin:

Either way, you’re right: The best solution will be the one that is modular and accommodates everybody’s needs :+1:t2:

2 Likes

And it feels natural for others too, it seems it’s already used in Semantic Media Wiki :slight_smile:

I think the ::, comes from some programming languages, where

foo :: a 

It’s read: "the name foo is a value of type a".

2 Likes

IMO, having the link type in the front of the link ID has a few advantages:

  • most importantly, [[agrees with::LINKID]] (i.e., “this note agrees with the linked note”) reads much more natural than [[LINKID::agrees with]]; the latter may even be confusing since it looks as if it has the reasoning backwards (“the linked note agrees with this note”)
  • the link ID may already be followed by an optional link title or heading reference whereas the position in front of the link ID hasn’t been occupied yet
  • speaking of other tools, I have implemented the [[link type(s)::LINKID]] syntax for my own app, and AFAIK @Emile is also thinking about supporting this inline syntax for his Juggl graph view plugin for Obsidian.
4 Likes

Interesting! I actually think of it with entirely different semantics. Your way of approaching it is perfectly fine, but I’ll explain my thinking as well, since I think it provides some different advantages:

Basically, I think in terms of “Link Group” as a noun phrase (Family Members), rather than “Relationship Type” as a verb phrase (is married to).

I ask myself “What group does the linked file belong in, from the perspective of the current file?” rather than forming a sentence “File A agrees with File B.”

Some examples:

  • [[John Smith::Family Members]] - John Smith is a Family Member (to this person).
  • [[LINKID::Supporting Ideas]] - The linked file is a Supporting Idea (of this idea).
  • [[LINKID::Consequences]] - The linked idea is a logical Consequent of this idea.

The main reason I think this way is to make my system more conveniently structured for future searches.

When I come back to an old file in my system, I find it more natural to say:

  • Show me all of this note’s Supporting Ideas.
  • Who are this person’s Family Members?
  • What are the Consequences of this idea?

Rather than:

  • Show me all files linked with relationship type “is related to”
  • Show me all files linked with relationship type “agrees with”
  • Show me all files linked with relationship type “logically implies”

It is an extra mental step to ‘nounify’ relationship types (“agrees with”) into link groups (“Supporting Ideas”), but it’s an extra step that I find healthy for long-term clarity and organization in my system. It forces me to ask bigger questions about the structural outline of the information I’m mapping and how many types of relationships I actually want to track.

I much prefer to have a few organized groups (“Family Members”, “Hobbies”, “Professions” etc.) over an unmanageable number of semantic relationships (“is married to”, “is the son of”, “is the father of”, “plays the sport”, “studies the field of”, “frequently travels to”, “works as a”, “freelances as a” etc.).

Of course, this is just my way of thinking, and I’m consciously choosing to sacrifice some specificity to gain long-term simplicity and scalability.

Like I said, your method is great as well :+1:t2:

Just wanted to put mine out there as an option, in case someone else resonates with it :sunglasses:


P.S. Hilariously though, after all that explanation, I really wouldn’t mind placing the link type first as you mentioned. It makes little difference to my thinking approach, since I’m not using sentences to type my links.

1 Like

Thanks for the explanation. I also think that your “link groups” would work equally well when placed in front of the link ID, e.g. like this:

[[Family Members::John Smith]]
[[Consequences::LINKID]]

Also note that my verb-style link types (like “agrees with”) were just examples. You’d be free to use noun-style “link groups” instead. I’ve called the latter “link tags” or “link labels”, but there’s no real difference. Even “link attributes” (key/value pairs such as [[quantity=3::LINKID]]) could be used.

2 Likes

Definitely! It’s really cool to see how everyone is using Obsidian / Markdown for personal knowledge management. If we can get native support for link types, it’ll be huge :grin:

1 Like

Don’t forget that in tools like Obsidian, we can have auto-complete! That certainly would help limit an explosion of predicates :).

I prefer ‘link type’ first because it feels natural for me, just because the languages I write (Spanish and English) are subject-predicate-Object based, and writing the link type first won’t interrupt the writing flow.

The only thing that worries me with the notation [[Family Members::John Smith]] is that Obsidian currently parses this as:

[[__This__]] --unnamed--> [[Family Members::John Smith]]

And also might be interpreted in strange ways by other editors.

I imagine a new pair of symbols (like << >>) would not break existing functionality, such as the crucial Obsidian’s ‘rename.’

It could be used like this

<< [[Family Members]] [[John Smith]] >>

Or just embedded in the text…

and then,  << my uncle [[John Smith]] >> said...

I don’t know (I haven’t experimented with it yet).


Note: I’m borrowing the << >> from the RDF* (RDF Star) notation invented not long ago in the Semantic Web Community to describe graph data.

:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
1 Like

Use case or problem

  • In my workflow, I create permanent notes thanks to multiple literature notes.

  • I go in the permanent note, open the backlinks pane in the right sidebar, and start writing thanks to the literature notes content (From the backlink on the top, to the backlink on the bottom).

  • Since I process the backlinks from top to bottom, once I’ve processed some backlinks I don’t want to see them anymore, I just want to see the ones I haven’t processed.

Proposed solution

Solution 1

Thus, it would be cool to give “states” or “tags” that are proper to backlinks. Then, we could put some backlinks of the note containing the tag “processed” in some “backlinks folder” similar to the current ones (linked mentions and unlinked mentions) to then be able to show them or not.

To do this, maybe we could add a variable to each backlink that the user could change if he wants? (see figure)

Solution 2

Limit the solution 1 by just putting a “check” mark on the blocks of content of backlinks. If a backlink is checked, it goes in the “check” backlink folder. If it’s not, it doesn’t.

Current workaround (optional)

For now there is no workaround, really, I have to remember which backlinks I processed and which backlinks I didn’t.

Related feature requests (optional)

1 Like

@Rickykey Would the following request solve your issue?

1 Like

I would say partially! Because then I would just have to mention the litterature notes as “sources” in my permanent note. The feature you shared would then allow to make the entire notes disappear once i’ve processed them.

But I was talking about going even further, where you would process the content at the “block” level and not at the entire note level.

So in a sense it would help but not entirely. The link types would completely solve it.

For a minimum viable case: What about simply having a token within note that, if present, becomes the link (words along the arrow/edge/arc) name?
If your note contains characters between percentage signs then any outbound links get the text as the arc alias. e.g. %eat%

image

3 Likes

I would love to see that feature or community plugin in Obsidian. Could you share your current workaround with us?

Graph View is cool. In fact, it was the main feature I liked when I heard of “Obsidian” a year ago. I am a mind-mapper myself, and a Database-lover.
So, while I love to work on my Notion, it lacks so hard a mind-map structure, and I’ve tried alternatives to that.
Currently I use the Brain. and being honest, its expensive, and lets say it feels a bit out-dated in style or else, but it gets the work done as a wiki-mind-mapper.

So Obsidian sounded very cool to me. but Graph-view, a year ago, was very primitive, compared to today of course. so I didnt use it as I would like.
Nowadays, though, is more robust, and overall Obsidian is adding very quickly a ton of features (and this encourages me to keep using it).

well…so the mind-map part: Currently links keep being just some lines (with maybe arrows) that cant be edited in any way.

Maybe we could make links between Nodes to have different colors, names attached to them, or icons, or maybe even notes. ??? (a nice group of features found in TheBrain)

thanks for listening
cheers, team!

1 Like

My story is a bit similar.
I was in the market for associative notes a year ago, and the choice came down to TheBrain vs. Obsidian. I felt like Obsidian was too ripe, and so I went with TheBrain, which decently suits my needs even today.

But Obsidian has since progressed greatly, its fast, simple, with a transparent folder structure, and a nice dynamically generating graph.
I want to really use it, but the only thing that it’s really missing is types of links.

In fact, what I only really need is having just 2 types of links (hierarchical parent/child relation and some kind of free association). + Being able to filter them out on the graph.
I think they could be nicely visually distinguished by solid/dashed lines:

Having these would not hurt the simplicity of Obsidian’s architecture, but would greatly improve comprehension of the connections between the notes.

2 Likes

Something like this can be done through the Juggl plugin. For now, the edges are configured through CSS, but the developer plans to add this feature to the main panel.

4 Likes

I very much like the approach taken in TheBrain where a link is more than just a cross-reference, it is a primary entity (property holder) that can have a note and other attachments associated with it that describe the nature of the link.

It isn’t easily possible to emulate this feature in Obsidian. If I link Page A to Page B the current method to describe the nature of that link is to put it into A or B or both (bad duplication) and possibly create a block link. The only way to avoid this is to put the details of the link into a new page ©. If I then link A->C->B I would lose the direct link A->B in the graphview. If I create A->B and A->C->B I start to introduce obfuscation.

This isn’t a problem in TheBrain because the primary display is graphical so A and B appear as nodes while C is a directed arrow between them. The arrow shows that they are linked while a note attached to that link © can be used to describe it’s nature. There is no difference at all in the status of a note attached to a link compared to attached to a node.

I hope this makes some sort of sense.

4 Likes

Hi Zac! I love your use cases and sample GIFs illustrating them, very well done!

I just made a feature request that could actually solve both of our needs:

Here’s how this simple attributes feature would work:

I want to make this paragraph have its own class. {.foo}

Furthermore, I want to give [[This Page Link]]{.bar} its own class.

Lastly:

- this list
- should have
- a third custom class
{.baz}

Now you may be thinking, “this doesn’t solve my use case”—but it’s usable for any attributes. For example, are you familiar with XFN — the XHTML Friends Network? It lets you establish relationships using the standard rel="" attribute, so a relationship link could be defined like this in markdown:

Meet my partner, [[River Song]]{rel="partner"}.

Looking for something more specifically tailored to your Obsidian needs, like wanting custom filterable options in the Graph? If the Obsidian team implements this markdown-it-attrs feature request, then they could support your exact needs with something like the above (parsing the rel attribute for graph filters, for example), or:

Meet my partner, [[River Song]]{data-obsidian-graph-group="Partners"}

The data-obsidian-graph-group would find all unique values (“Partners”) and turn those into filter options as a group.

Additionally, this proposed feature request for markdown-it-attrs would allow for customizable aspects to lots of areas of Obsidian, using that data-obsidian-X syntax. It’s all up to what the devs would want to allow and implement, but the idea of customizable graph filters is awesome and I would love to see them implement this!

3 Likes