I think as superset of this feature, having link types makes sense too for better organisation. I used to use TheBrain (previously PersonalBrain) which had this link type feature among nodes. Granted it was mainly a mind-map type app, whereas the graph is one feature in Obsidian but I think since the core of Obsidian is still notes and the connections between them, it makes sense.
Link types can help establish certain relationships that we cannot do now like,
Parent - Child
Sibling (default as it is now)
Directional
Task/area assignment
Status (under consideration, ongoing, established, etc.)
Absolutely - The Brain is the gold standard as far as Iām concerned when it comes to visually linking notes. I never got into using it, however, because it is TOO visual and the text features were too cumbersome.
4 or 5 years ago I tried to hack together a bunch of d3js code snippets to basically create a poor manās Roam/Obsidian, being text-first with a filterable, customizable, zoomable, node-centering network map, but I didnāt have the capabilities to make it anything beyond a very crude alpha.
Iām delighted to see all these text-first tools coming out now, but the graphing capabilities are nothing short of unusable. I look forward to whatever progress is made on this front - but first the basics of the editor, linking, etcā¦ need to get ironed out. The priority, after all is on linking the content, the text, the ideas of notes, not just the notes themselves.
But even in a good interface, like Roam, people tend to be focused on the latter - linking as many low-quality, meaningless notes as possible, instead of focusing on creating good notes/ideas first and then link them meaningfully. Thatās user error though - and starts to get into notions of philosophy, ability to think, have perspective, have principles and frames of references, have an actual (worthwhile) goal that can help orient your efforts, know what is actually important, and leave the other 95% of your shower thoughts either unlinked or in the shower.
According toTim Berners-Lee, āA typed link carries some semantic information, which allows the system to manage data more efficiently on behalf of the user.ā
This page sketches some of the most essential link types. Here there is much more. I was introduced to the concept of ātyped linksā at the first international Hypertext conference in 1987.
I still havenāt seen many decent implementations of this essential concept to building a second brain, in spite that it is essential to the semantic web. Drupal has a dev. ātyped linkā project
While it is very nice to see connections between different notes/subjects, it is somewhat lacking (in the context of graph view) that you canāt immediately point out what links two nodes together.
Sometimes you can recall just by association.
And sure, you can always get into the notes and figure out what gave birth to the coupling.
But wouldnāt it be nice if you could name a certain edge and have the name pop when you hover over it with the cursor ?
I think such feature would increase the value and usability of graph view significantly
Use Case:
As a User I want to create relations between notes by using a plain markdown syntax or markdown extension.
Possible Implementation:
In Plain Text via Markdown Extention:
Like using an markdown extension like Link to Headings with [[Note1#Heading1]] or Alias [[Note1Titel|DiplayText]] there could be a further extension like [[Note2::relation::]]
In Graph View: Sample:
Note āMotherā contains a Wikilink to [[Father::married to::]] then the graph shows the following relation:
Mother ---- married to ā> Father
Rdf or linked types are and will be the game changer for personel knowledge management systems. Ä°magine a plugin run sparql querries on your pkm. Ä°f someone also add variable functionality. (Put here a meme says āshut up and take my moneyā).
[[this is a link]]
[[this is a link|with different text]]
[[this is a link|with different text|exampletype]]
[[this is a link||exampletype]]
Thatās easy to type, differentiates easily in edit mode (to my eyes anyway), can be easily search and replaced/grepād for bulk edits, and contains all of the link information inside the link brackets (which appeals to my sense of info heirarchy organisational tidiness )
Thereās a complexity here to do with the linking direction and rendering in the graph view. Your example:
Mother ---- married to ā> Father
should actually be rendered:
Mother <-- married to ā> Father
Or possibly without arrow ends at all. It makes sense to read that particular relationship both ways. But [[Child::gave birth to::]] only makes sense as:
Mother ---- gave birth to ā> Child
In the Mother note you might also want to write [[Father::proposed to::]] which I would read as:
Mother <-- proposed to ā Father
And yes, I know that could be interpreted the other way around as well - Mother proposed to Father. My point here is that itās ambiguous.
PS Donāt get me wrong here, I want link types rather badly. Iām just talking thoughts out here to try and refine how they could/would work.
Consider also the Semantic MediaWiki syntax where the optional property portion of the link is actually a prefix like if your Berlin.md page had a link:
[[Is Capital of::Germany]]
ā¦which linked to Germany.md and established the relationship:
So you have two notes - āmotherā āfatherā
And youāre looking at links. Just think how many there will be of different types. True that each one you add will be specific when you add it, but the link network will be awash with them.
My feeling is that, for something like this to be added, it ought to include ways of dealing with issues like these.
Could be a linktype equivalent to a MOC list, where āmotherā āfatherā are the notes at the top and thereās a list of all link types that have been identified between them. Married could have at least three possibilities - religious, civil, legal. Everything would depend on what the user was interested in.
That little example has two notes and one āexplicitā link. The link in the opposite direction is inferred through a rule, not explicitly written down. It was an example of how to have bidirectionality and avoid duplication.
I donāt understand why the number of types (link names) would be an issue, I believe users can figure out how many different types they want, and how to use them.
Do you mean to assign link names which can be also a Note? That would be awesome! It would keep things consistent. Having ālink typesā as regular notes allow to explain them and relate them together. Perhaps even write down properties such as symmetry, transitivity.
Example:
Note āMotherā
# Mother
This [[Is a::Person]] [[Married to#civil::Father]]
in the note āMarried toā (which is a type)
# Married to
This is a [[Is a::Type]] and [[is a::Symmetric relation]]
## religious
Explanation...
## civil
Explanation....
Iām considering using the link-to-header syntax right now, actually, since it sort of already works and I can grep them etc. So in the Berlin.md case I can write my link like:
[[Germany#:is capital of]] and it still links to Germany.md.
It renders in the HTML as: Germany > :is capital of which also isnāt so bad.
The : bit after the # tells me Iām doing this for semantic linking reasons and it also wonāt conflict with any existing headings in the document.
Iāve also discussed semantic links (or āqualified linksā as Iāve previously called them) over at the zettelkasten.de forums. There, Iāve suggested the following link type syntax:
The ideas in this note are further extendend in [[is_extended_by:20201113]].
These statements question the conclusion that [backlinks are useful](critiques:Why_backlinks_are_useful.md)
Reading the comments in this thread, I think that the use of double colons (i.e., [[type::link]]) may be even better, since its used elsewhere already and is likely easier to parse. Also, a rather unique sequence has less chance of colliding with other uses (e.g., single colons in bibliographic citekeys, like miller:2019).
For bibliographic citations and links between literature notes, the CiTO ontology could be used which already offers a comprehensive set of relationship types. Software could offer these relationship types via autocompletion when composing a link.
The use of semantic links would allow software to label connections in graph visualizations, or to filter a graph by a certain relationship type. These are just a few examples, of course.
IMO semantic links have a huge potential to further advance what knowledge management software can do.
The semantic relationship between [[wiki links]] is always present in the sentence where its used. For example,
[[Berlin]] is the --capital ofā> [[Germany]].
The [[Cookies]] --are insideā> the [[Jar]].
So I feel, we could simply highlight the part of sentence that describes the relationship (as shown above) and the resulting graph could look like this.
I feel this could be an elegant solution for providing context to the links.
For a cleaner look, we could even choose to hide the arrow syntax in preview mode and only use it to identify and display the label in Graph View.
Access to frontmatter is supported in the Obsidian API (through CachedMetadata). So a plugin could tackle this, maybe! In this example, topic1, topic2, author1, author2 and Germany would be wikilinks. Although Iām not sure if thatād be correct syntax (should it be double brackets?).
A downside of this is that it doesnāt allow inline typed links.
