The Case for Custom Link Types

Thanks for creating org-roam and improving it on a daily basis!

It would probably be a good idea to modularise org-roam--extract-links. Especially the part that identifies and handles the link types. So anyone can write a package as an extension that creates additional links without affection org-roam itself. Maybe a custom variable that holds a list of functions of link types and properties.

Custom link types could be able to set the default columns (from, to, but probably also add columns to the link table or store values in a meta column. Or add its own table to store the data there.

Of course there also needs to be a way to change the behavior for those links in the side buffer.

Use Cases

Some posts in this forum could benefit from this: Custom Roam-style link and Add Link-tags feature and maybe Customize display of cite links.

More use case derived after checking out the features in Luhmanns Zettelkasten (unfortunately only in German) by

  • having a look at the actual Zettels (notes), which are available online (niklas-luhmann-archiv.de). So far mostly Zettels from the ZK1 are scanned and transcribed. Zettels from ZK2, which he started later on and is a bit more advanced, are unfortunately not available yet. But some are shown and discussed in the videos and the article.
  • reading an article about the Zettelkasten on the same page
  • watching two videos about the Zettelkasten (1, 2)

Luhmann used 6 (that’s my conclusion) types of Zettels and they really make sense:

  1. Notizzettel (note) - 75.000
  2. Bibliographiezettel (bibliography note) - 18.000 In ZK1 there are multiple references on one note and multiple notes in sucession. In ZK2 there is one title per note. He placed those bibliography notes in a separate part and of course linked to them from other notes.
  3. Schlagwortregisterzettel (tags note) - 307 A collection of tags in alphabetical order (tags, keywords) with links to notes. Luhmann has noted a maximum of four references per keyword. The reason for that is that he only linked to sort of entry notes. From that note he was able to dive deeper. He had 4.450 tags (crazy).
  4. Sammelverweiszettel (index or reference note) - ? At the beginning of a topic there are notes referring to a number of other notes (link includes a term/topic/tag). These reference notes offer the possibility of indexing from one point numerous notes in the collection that are related to a specific topic.
  5. Literaturzettel (readings, literature or research note) - ? Almost identical to the index note. But instead of references to other notes it is a list of books etc. to read placed at the beginning of a topic.
  6. Gliederungszettel (outline note) - ? Several aspects to be dealt with which refer to a correspondingly designated note. Those notes are once again placed at the beginning of a topic. The aspects are in a certain order/structure and more aspects are added over time.

1, 2 and 5 can be handled with org-roam as it is. The other type of notes would be doable by using custom link types.

Tags note (tags links)

To apply what Luhmann does to org-roam it could be just org headings (this has the advantage to mark tags or link headings with keywords like TODO or NEXT or set the archive tag):

* Knowledge Management
** [[roamTag:20200518125141-zettelkasten.org][Zettelkasten]]
* Learning
** [[roamTag:20200309214122-how_to_learn.org][How to Learn]]
** [[roamTag:20200310091708-learning_how_to_learn.org][Learning How To Learn]]

And then I could write a package that identifies those tag links and uses ivy to show completions for this index note as follows :

Knowledge Management > Zettelkasten
Learning > How to Learn
Learning > Learning How to Learn

To keep it as simple as possible it uses the heading (or outline path if more than one heading) above the link as tag. It would be possible to even show more levels of related notes:

Knowledge Management > Zettelkasten
Knowledge Management > Zettelkasten > (bib) schmidt_zettelkasten_2016
Knowledge Management > Zettelkasten < Zetteltypen
Knowledge Management > Zettelkasten < Zetteltypen < Notizzettel
Knowledge Management > Zettelkasten < Zetteltypen < Bibliographiezettel
Knowledge Management > Zettelkasten < Zetteltypen < Schlagwortregisterzettel
...

Such tag notes could be placed anywhere. Also embedded in a normal note.

Index note (index links)

Almost the same as the tags. But another style of link that can include a word/subject like in the proposed link-tags feature and/or the title of the target note. So they don’t rely on a heading structure. If no term is included, it is of course just the title of the linked note.

It’s sort of up to the user how those links are used (which is great):

- [[roamIndex:20200309214122-how_to_learn.org][Learning » How to Learn]]
- [[roamIndex:20200309214122-how_to_learn.org][» How to Learn]]

* [[roamIndex:20200309214122-how_to_learn.org][Learning » How to Learn]]
* Learning [[roamIndex:20200309214122-how_to_learn.org][» How to Learn]]

Of course there also would be an ivy/helm interface.

Outline note (outline links)

An outline is used to have an outflow of the Zettelkasten (Building Blocks of a Zettelkasten, How I use Outlines to Write Any Text). Not sure if this is what Luhmann did with those notes, but it makes sense.

The outline can be a simple list with links to notes, but usually grows into a structured list using headings. During the creation of the outline, gaps will appear, which will be filled with research and further notes.

Special about outline links is that they should offer a possibility to include/embed (#317 [Wishlist] Enable embedding blocks) the text of the linked notes.

So those outline links can be used and then there is a functionality to embed the content below the link.

* TODO Zettelkasten  [0/3]
[[roamOutline:/home/hubisan/org-roam/20200518125141-zettelkasten.org][§Zettelkasten]]
** TODO Zetteltypen  [0/7]
[[roamOutline:/home/hubisan/org-roam/20200523174853-zetteltypen.org][§Zetteltypen]]
*** NEXT Notizzettel
[[roamOutline:/home/hubisan/org-roam/20200524091229-notizzettel.org][§Notizzettel]]
*** TODO Bibliographiezettel
[[roamOutline:/home/hubisan/org-roam/20200524091520-bibliographiezettel.org][§Bibliographiezettel]]
*** TODO ...
** TODO Verweistypen [0/0]
[[roamOutline:/home/hubisan/org-roam/20200524225656-verweistypen.org][§Verweistypen]]
** TODO ... [0/0]

Hope this makes sense.

1 Like

I might suggest something like “Hub notes” as well, which are like structure notes but not (necessarily) hierarchically organized. I’m not sure if that’s what you mean by “index notes”. Luhmann’s index notes didn’t aim to collect note links topically like this, but just to offer a limited number of ‘entry’ points to the networks of permanent notes. Luhmann also had “hub notes” to create longer lists of topically-related notes.

Hub notes is what I named index note. Hub is the better term for it.

Here is a Zettel for each from Luhmann:

Bibliography note

A collection from ZK1. Single notes are not available yet as they are in ZK2.
https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_2_BG1a_001_V
image

Tags note

https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_2_SW1_006_V
image

Readings note

https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_1_NB_17_1_V
image

Hub note

https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_1_NB_17_2_V
image

Outline note

https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_1_NB_17-11e_V
image

I am confused by the use cases, since it seems much more like different note types rather than link types, and it doesn’t seem like you would need separate types of links to work with these types of notes. The exception possibly being the tag notes/links with the breadcrumbs, but I don’t understand what those are being used for.

That said, I do think modularizing links is a good idea. However I don’t know if it’s bad practice to potentially have an unknown number of external modules modifying the database schema, or how to best integrate search/completion functionality for different modules (if they should be integrated at all, or if they should just be 90% copied, 10% modified, and a user will have multiple functions for multiple modules).

This was my initial reaction as well; can’t we already do this with ROAM_TAGS?

Hoping the OP can clarify.

Your replies made me think about this again.
Before posting this, I also thought at first that it is a type of note.

But after some testing/thinking I realized that those notes can be a part of any normal note. So it seemed impossible to identify the special backlinks and handle them in another way.

That’s why I came to the conclusion that it should be links and not notes. So I can include them everywhere I feel like so. But still not sure if this is the right way.

The tags links are not like the current tags implemented and it should not replace those at all, it’s an additional feature. The tags are obviously not inside the notes, it’s more of a managed and scannable index file that links to notes. The advantage is that I can manage it with all what org-mode offers: Subtrees, todo keywords/schedules for tags or links below it, annotations (normal text below the headings), properties, searchable by default with for instance counsel-org-goto and much more.

The breadcrumbs help me to see the context for a note and make it searchable. For instance if I want to check all Zettelkasten note types (for Luhmann it was seperate notes, but that was with using paper only) I just search in ivy completion for “zettel note” and I will get all types I am looking for. If I want to do that with org-roam I go to the Zettelkasten note, then follow a backlink to note types and then check all backlinks. This is more complicated and this is a very simple case. The more complex the better those breadcrumbs get. Or I tag everthing related to Zettelkasten with Zettelkasten in org-roam to make it searchable. But then I will have too many tags soon that there are so many trees that I can’t see the wood anymore (literal from Germann).

Can you follow my thoughts? Do you any other ideas to handle this without the need of custom links?

As you mentioned, changing the DB with an extension is probably not a good idea. Some conventions on how a package can store data are probably needed.

Could you clarify how this might be a separate case from using a link-tags approach? Like I said I like the aspirations of a modular design, but I have been trying to imagine what other cases I could come up with that don’t fit under plain links and backlinks, note-tags, and link-tags, and I can’t really come up with much. Maybe some very specific details, but nothing that made me want for a completely new link-type. Could you give an example of something you would want to do in org-roam, but currently can’t, and how one of these new link types solves the problem? I think I am just not understanding the problem scenario you are presenting.

This sounds like a hierarchical design, which is something I generally want to avoid. A complex breadcrumbs trail means my notes are harder to find, or end up endlessly categorized under different, specific schemas.
Or at least I’m not understanding how this is different from using multiple note-tags (ROAM_TAGS). You will end up with many note-tags, but how is that any different than the tag links? Wouldn’t you end up with the same number of tag links? You wouldn’t have breadcrumbs maybe, but again that makes me think this is a hierarchy like a bunch of sub-dirs.

Is the idea that you could have note-tags which form arbitrary hierarchies – so they aren’t flat like regular tags, but you also don’t need to keep notes separated in actual sub-dirs?

FWIW I did a little searching and it looks like extending a db with additional tables in modular app design is, at least, not uncommon. Some comments made it seem like storing even several hundred tables doesn’t impact performance, and you could keep the modules separated that way while sharing the data they needed in common.

No :wink:

You list a series of note types: “hub notes,” “bibliography notes”, etc.

From my understanding, those distinguish types of note (objects), and so can and should be designated using ROAM_TAGS. Certainly an explicit use case for these note tags was bibliography notes.

So, for sake of argument, if you had separate directories for each note type, and set setq org-roam-tag-sources to use the directories, they would be tagged with those directory names, and you could filter search results based on them.

I want to understand this part first before trying to understand how links (relations) fit.

I realized that it is probably better to grow my org-roam for half a year and then post a follow up with a working prototype of what I envision.

Maybe I will conclude by then, that it is doable with what org-roam offers by then.