# Graph theory: Contraction, applied to the Zettelkasten

## Graphs

In abstract graphs, you can remove edges connecting notes via contraction. Illustrated below you see that the highlighted edge $e$ is removed in such a way that the node $y$ is removed as well. To not destroy the path from $x$ via $y$ to $z$, the formerly indirect connection becomes a direct one:

## Applied to Zettelkasten

• Imagine each node in the graph is a note in your Zettelkasten.
• Imagine each edge in the graph is a link from one note to another. (We actually would need arrows/directed connections)

Then the operation above could be applied to e.g. export a sub-network of your notes while skipping some notes in the process.

Say you want to share your Zettelkasten department on backyard gardening with your neighbor Phil, but you also have notes on Phil, ridiculing his short cucumbers. Glad that he finally admits your large cucumbers are the source of his envy, you don't want to export any note tagged #neighbor_phil, but you also don't want to break any existing links.

Contraction could remove offending notes, and replace links to e.g. [[201812241555 Phil's laughably stuffed turkey]] (effectively skipping it) with any outgoing links from it to "bridge" the gap.

## Example

The graph operation depicted above is simple to implement as a data structure in code; but on the level of actual content, of text and hypertext, doing this sensibly isn't trivial.

Given a piece of text like this:

This is a paragraph[[202112111341]] of text


How would you remove the link to 202112111341 and replace it sensibly?

1. The note 202112111341 doesn't have any outgoing links -- then you can just remove it.
2. The note 202112111341 has 1 outgoing link to 201310221352 -- then you can one with the other.
3. The note 202112111341 has 2+ outgoing links, to 201310221352 and 201208162120. How do you splice these in without breaking how the text reads?

The worst case (3) could be rendered as naive replacement:

This is a paragraph[[201310221352]] [[201208162120]] of text


But maybe none of the two spliced-in notes are actually about "paragraph" so they don't make sense there.

Mechanically appending these links would also work, and it would admit that in-place replacements don't (always) work, but it also has drawbacks:

This is a paragraph of text

Also:
- [[201310221352 Movable type]]
- [[201208162120 My favorite cake recipe in 1 paragraph]]


(See, one of these wasn't even on "paragraphs"!)

## Existing literature?

Has anyone of you with all the graph smarts read a paper on hypertext graph modifications like that by any chance?

I realize that semantic links could help. In the link chain from note A→B→C, semantic annotations could be:

A --(refuted by)--> B --(supported by)--> C

There, you cannot simply stamp-out B in the and re-use any of the existing edges/arrows:

• A --(refuted by)--> C may not hold when used that way
• A --(supported by)--> C is very unlikely, given how B→C and A→B related

Tricky!

Author at Zettelkasten.de • https://christiantietze.de/

• First, personal opinions about your neighbor's cucumbers are not subject to building knowledge and are best recorded in a separate journal. Journaling in your PKM is a messy and very bad idea. This would make this sticky situation unlikely. However, you still will want to exclude some nodes when exporting an idea graph.

One way out of this dilemma is to use new link IDs. No rule says a note/zettel has to have only one UID. In the example, a new UID is created [[2024080210551]] and placed in the YAML of node $z$ and $e$, and it would replace the $y$ providing a direct connection. This new UID would be used for connectivity and not have a note associated with it. This is an advantage of the "link as search" as opposed to "link as title/filename."

Given a piece of text like this:

This is a paragraph [[202112111341]] of text with a link [[201603281221]] or two.

How would you remove the link to 202112111341 and replace it sensibly?

Using the secondary UID, the text would read.

This is a paragraph ◊[[2024080210551]] of text with a link [[201603281221]] or two.

I suggest that prepending an indicator, like "◊, " to this type of link is appropriate because it does not behave normally. One feature of this method is that the secondary UID can be placed on multiple notes/zettels satisfying different scenarios.