Add support for link types

Feature requests
,
14

Hi! Thanks for the examples:

[[this is a link]]
[[this is a link|with different text]]
[[this is a link|with different text|exampletype]]
[[this is a link||exampletype]]

I think they are easily parseable and won’t break things around. I’ll use them in the meantime :slight_smile:

Regarding linking direction,

If you declare:

Mother ---- married to —> Father

I believe it should be rendered just like that, in one direction.

Unless your system has a rule about the property ‘married to’, for example:

If x is married to y then y is married to x. (symmetric)

Then it can infer: Mother ← married to —> Father

Link types allows reasoning, so you don’t need to type all knowledge explicitly

I really want link types too,
and I’ll start writing them to parse them in the future with Obsidian or a plugin/script

3 Likes
17

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:

Berlin --> Is Capital of --> Germany

13 Likes
18

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.

19

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

That way of writing types is really cool! thanks!

2 Likes
20

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.

3 Likes
21

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:

Similar to semantic citations used by Pandoc Scholar, Markdown links could incorporate a relationship type like this:

[[type:link]]
[[link description|type:link]]
[link description](type:link)

Examples:

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.

6 Likes
22

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

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.

what do you guys think?

10 Likes
23

Obsidian supports YAML frontmatter since v0.9.16 (when it introduced aliases).
Maybe typed links could be supported in this frontmatter? Eg

---
aliases: [alias1, alias2]
topic: [topic1, topic2]
capitalOf: [Germany]
author: [author1, author2]
---

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.

8 Likes
24

This doesn’t allow inline typed links but allows us to say something about the note itself. It seems like an excellent start for me :).

On the practical side, I would go with double brackets, so we can still use auto-complete.

I also dream about having the possibility of using entities as properties. But I don’t think that front matter allows this.

Would that be something nice to have?

---
title: awesome recipe
[[has ingredients]]: [[ingredient1]], [[ingredient2]]
[[preparation time]]: 5 minutes
---
7 Likes
25

Double brackets makes sense, but I think licat mentioned that it’s currently not recognized as a link.

And using entities as properties maybe sounds a bit confusing: It’d be both a node in the graph and an edge. And not so sure what the use would be for this? As long as you can query all has ingredients relations.

1 Like
26

True, it’s not recognized.
You cannot ctrl+link inside the note :cry:

I was thinking about describing the properties themselves, which is useful when your Personal Wiki is a mix of Wiki and Database.

But now that you say it, it’s confusing. Also, Front matter is already defined as YAML or TOML. (do they allow double brackets [] ?)

1 Like
27

For now, to describe complicated stuff inside my notes,
like formulas, graphs, multi-arrays, whatever.

I’ll write:

` ``yourPreferedDialectToDescribeThings

The contents

` ``

And then have scripts or plugins to extract and consume such data. That would do in the meantime, I guess

1 Like
28

It is worth looking at Neo4j. They created a cypher query language that allows you to have relationship types. The syntax if pretty straight forward too.
(:person) --[:works for]–>(:company)
(:person) --[:owns]–>(:car)

9 Likes
29

This might be even better

What is Aspen?
Aspen is like Markdown but for graph data.

  • Nobody

Aspen is a simple markup language for creating graph data.

Aspen lets you write about people, places, things, and the relationships between them using marked-up text, and converts your text to valid Cypher that can be used in Neo4j graph databases.

So, Aspen is both a markup language and a software tool that converts text to Cypher.

Aspen does not aspire to be a query language—Cypher is a truly elegant language for querying graph data, and we’re frankly in awe of it. Aspen is intended to make it easy to write graph data by hand.

8 Likes
30

Proposed solution using existing syntax for adding metadata/attributes to markdown elements, including links:
(I would prefer extension to YAML or at least JSON)

---
id: NoteMe
title: king Me
aliases: [little king, small king]
---
# king Me
King Me had three children: 
- [Alice](noteA){link-type: parent-child}
- [Bob](NoteB){link-type: parent-child, probability: 1}
- [Charlie](NoteC){id: LinkID123, link-type: parent-child, probability: 0.5, paired-link: "C#LinkID124"}

Links would be understood as links between current note/node(subject) and link-target(object).
In the future they could be queried/analyzed/visualized using e.g. Neo4J/Cypher. (Either externally or in Obsidian if it gets integrated with Neo4j/Cypher.)

Initially, link type can be specified by syntax used to assign class ("." prefix), we can even specify multiple relationship types in one link: “[Alice](NoteA){.parent-child .loves}”. This might cause collision with other uses of classes so there could be dedicated syntactic-sugar for link-type (":" prefix) just like already existing for id ("#" prefix) or for class ("." prefix). Then we would have:

...
# king Me
King Me had three children: 
- [Alice](NoteA){:parent-child :loves}
- [Bob](NoteB){:parent-child, probability: 1}
- [Charlie](NoteC){#LinkID123 :parent-child, probability: 0.5, paired-link: "C#LinkID124", updated: 2020-11-24}

The metadata could be assigned to inline links manually or automatically (either permanently or temporarily) by Natural-Language-Processing of surrounding text, e.g. using Aspen.

Except [syntactic-sugar for link-type] which resembles Cypher, this would not clutter the world by any new syntax while allowing full, extensible functionality.

Edit 2020-12-29: Idea to mark link type by colon prefix might be incompatible with marking link-states in css https://www.w3schools.com/css/css_link.asp so we might need to live only with classes and key-value pairs. I do not understand enough CSS yet to determine this.

4 Likes
31

Workarounds:
In YAML, [[name without comma or colon or brackets]] is an array containing only one element, which happens to be a again an array containing only one string “name without ... or brackets”. We could interpret YAML/JSON substructure with such properties as a link to innermost string but that would be implicit, not explicit.

Option: We can enclose each link in YAML in quotation marks to store it as quoted string "[[link]]" or '[[link]]'. Some characters like # and other need to be escaped in these.

Option: AFAIK, we can use YAML block scalar to store any text without need to escape anything.
Just introduce multiline string by pipe character and put the content on the next line. Indent the content more than the line above (by spaces, not tabs).

key: |
  # headings, 
  [[links]], #tags, {}
  C:\paths with\backslashes\
  etc
  can be used in multiline string (YAML block scalar)
  It starts on next line after pipe character indicator. 
  Just indent each line of string by more spaces than the line above string.

Links in front-matter were also discussed in Include / show note links in yaml frontmatter (v0.8.5)

Strings stored in YAML would then need to be parsed as markdown
Alternatively, and then parse strings within parsed yaml as markdown (both, keys and values) to see if they match wiki-link syntax.

Option: we could specify custom data type before each link or hypertext. Possible results:

  • !link [[my link]]
  • !link "[[my link]]"
  • !link "my link"
  • !md "hypertext with [[my link]]."
4 Likes
32

Otherwise, there are several serialization formats for linked data.
“N-Triples” follows structure of sentence: "subject predicate object. " where each element is usually autolink to corresponding URL, i.e. url enclosed in angle brackets “< >”. There is no reason to disallow other syntax for links.
So any sentence in markdown matching the pattern of three consecutive links could be interpreted as typed link and converted e.g. to Cypher.
For example sencence “[[link1]] [link 2](link2) <http://example.com/link3>.” would become (link1)--[link2]-->(http://example.com/link3) in Cypher.

“Turtle syntax” allows to express multiple relations together more concisely by extending N-triples sentence format to nested structure similar to YAML.

Aspen is not restricted to one syntax but can easily understand any syntax proposed i this thread, according to:

33

This topic is most interesting topic in forum. And will lead us to another project. A markup format which can be querriable by sparql or cypher. Thats the future of text

11 Likes
34

There are several amazing ideas of how to express this knowledge. I wonder if it’s better to just embrace all these possibilities.

Some ‘dialects’ are super expressive, but also more complicated. Different tools for different tasks.

The good thing is that Markdown allows us to add code segments, where we can add whatever we want.


` ``triples

Here some triples

`` `

` ``cypher

And also some cypher

` ``

Perhaps the best would be to experiment with these, and use plugins that can extract and process the different ‘dialects’, depending on the task.

5 Likes
35

I’ve been working on a converter of Obisidian vaults to Cypher: Semantic Markdown converter: Visualize your Obsidian vault in Neo4j Bloom!

This allows you to define typed links as follows:
- linkType [[note 1]], [[note 2|alias]]

If people here are interested in different ways of specifying link types, let me know and I can implement it! (If it’s not too complicated :))

8 Likes