Add support for link types

Hi @cristian, as someone who was heavily into the Semantic Web work ca 2000-2003 I would agree, if it had actually developed into something useful and widely used. The fact that it did not indicates it was an ineffective concept, thus the web as it exists today has a fundamental lack of this capability.

@davecan , I differ.

Just one example:

When you search for ‘shoes’ in google, you get an info-box with structured data.
This data was gathered processing RDF embedded in the HTML pages.

This is widely used.

However, I agree that it failed as a concept. I believe we cannot represent 100% reality. But that’s another topic, I guess.

Adding my vote here that the externalized triple format proposed by @datum while interesting is absolutely not something I would use. My entire workflow relies on fluidity and I’ve gotten it (in an extremely short time – couple weeks) to a point where when I’m creating and linking notes it feels more like I’m interacting directly with the notes physically rather than working through Obsidian. Obsidian in that sense just melts away a little bit.

Expressing link types directly at the point of link definition is the way to go IMO. Requiring an external note to create the relationships through the triple format is friction that will almost never be used by me, and I would suspect others as well, because it interrupts the flow and forces us to stop thinking about our notes and start thinking about Obsidian again.

The colon-based format seems useful to me, but perhaps it should become a separate delimiter rather than using it after the pipe, since the pipe is already used to separate the file name from the display name which can be autocompleted from the alias front matter. I used this a lot since I prefix my notes with ZK-style UIDs.

Possible syntax alternatives:

  • [[the note:label|link text]]
  • [[the note|link text]]:label
  • [[the note->label|link text]]
  • [[the note|link text]:label]
  • [[the note|link text]->label]
  • [[the note|link text]]->label (risks collision with existing notes, but maybe not a huge deal)

I quite like the -> syntax in the third bullet…

@davecan, if you’re referring to my 12/19 post, it wasn’t my idea and I wasn’t supporting the notion. Actually I was explaining why it isn’t a good idea. I finished with:

Personally I don’t see this happening due to the ambiguity created.

I wish markdown had something to embed ‘invisible’ metadata.

At least for reference-style links/images in MultiMarkdown, one can add attributes to links and images in the link reference information, e.g.:

[link]:  http://path.to/link.html "link title" class="attribute1 attribute2"

These attributes won’t show up in a typical Markdown preview but can influence the rendered output, and could be used for semantic purposes.

I’d like to vote for a syntax like this:

[[optional link type(s)::LINKID|optional link title]]

Examples (for reasons of simplicity, w/o any link title/alias name after the LINKID):

[[supports::LINKID]]
[[refutes::LINKID]]
[[is confirmed by::LINKID]]

Double-colons as a delimiter for a link type prefix are already used by other tools (e.g. Semantic MediaWiki) so this would ease interoperability.

Also, this syntax travels with the link, and as such can be used inline. And it doesn’t spill outside of the main link delimiters ([[...]]), and would be rather straight forward to parse. In addition, it could also allow to set multiple link types, e.g.:

[[based on::confirms::LINKID]]

Finally, as discussed by @Emile for his Neo4j Graph View plugin, this could even support key/value properties, like:

[[has ingredient::quantity=50g::LINKID]]
3 Likes

The whole advantage of Markdown is that it is human and machine readable.
We can read and understand it easily in Preview mode and Edit mode.

The more complicated we make Markdown in Obsidian, the less readable it is in edit mode.

If we’re going to add link types in Obsidian, I think the answer lies in the YAML header and not in the notes because:

  1. That way we only see metadata when we’re trying to look at metadata
  2. Hides complicated syntax from novice users
  3. It just looks cleaner and easier to read.
4 Likes

I quite like the double-colon syntax. Another place that syntax is used is in Gitlab to distinguish between components in a label.

1 Like

Fair points @DandyLyons

1 Like

Currently, Remnote had relationship name/connection name / edge label in graph view.

image

like this one in Neo4j.

Use case or problem

As you can see here the data model consists of Nodes and Relationships. And both nodes and relationships will have properties associated with them. And together all of them will make a data model which will give us the better visual understanding of a dataset.

Properties are information associated to nodes. For example, if Wikipedia were one of the nodes, it might be tied to properties such as website, reference material, or words that starts with the letter w, depending on which aspects of Wikipedia are germane to a given database.

Labeled-property graph
A labeled-property graph model is represented by a set of nodes, relationships, properties, and labels. Both nodes of data and their relationships are named and can store properties represented by key/value pairs. Nodes can be labelled to be grouped. The edges representing the relationships have two qualities: they always have a start node and an end node, and are directed;[10] making the graph a directed graph. Relationships can also have properties. This is useful in providing additional metadata and semantics to relationships of the nodes.Direct storage of relationships allows a constant-time traversal.

Hope Obsidian have a way to implement it.

6 Likes

I wish markdown had something to embed ‘invisible’ metadata.

How about Open Graph Protocol?

  1. It’s “invisible”. Its just an HTML tag which will be invisible in Preview mode.
  2. It’s already an established standard with documentation.
  3. Fairly simple to write, read, and edit.
  4. It’s widely used across the internet (which means we may even be able to automatically import metadata by simply pasting in a URL into Obsidian): Automatically fetch and import metadata using Open Graph Protocol -> YAML Metadata
2 Likes

These are interesting points. Currently, for Neo4j Graph View, I’m having both a list of typed links like - hasTopic [[note]], and like @msteffens mentioned, I’m thinking of adding the double-colon syntax.

What could be changed here is to move or also allow the list of typed links within YAML frontmatter. Personally, I like seeing them rendered, though. The double-colon syntax would also be completely optional, so complicated syntax is hidden from novice users.

Furthermore, I think an inline syntax like double-colon is important! This is because it’s much more natural to write linearly. If you mention some fact in your text that you want to annotate, it wouldn’t be natural to move to the frontmatter to add this fact in the typed link syntax another time.

1 Like

Hi @Steve what is Remnote?, is it opensource? (curious)

I’ll add link to original post. I thought every obsidian user know remnote.

I’ve just tried it, but I cannot find the graph you presented.

There is also syntax for adding metadata to any markdown element used already in many implementations.
Request for official inclusion in Commonmark is here: https://talk.commonmark.org/t/consistent-attribute-syntax/272/22

I might post request to recognize this markdown extension here on Obsidian.


Another inspiration from RemNote: Display vertical context in long scrollable document (RemNote-like auto-folding mode)

Is it possible in Neo4J/Cypher for link/relation to be subject or object of another relation?
For Example:

([[A]] requires [[B]].)  implies  ([[A]] is member of [[set C]].) .

Could we use something like attributes with the “::” syntax (like Roam has) to help specify link relationships?

1 Like

For folks interested in the topic…this article might be interesting:

1 Like

This is a really well designed graph format!.. thanks!