How I use Folgezettel in unison with timestamps

amahabal

It has often been debated here whether we should use folgezettel in the digital context, often contrasted with the "timestamp method". This post is not intended to rekindle that debate (and that false dichotomy, as I now see it), but merely to report my method and how it helps me, in case others find it useful.

I exclusively used the timestamp method until I read the Bob Doto book, which completely changed by Zk practice, and now I happily merge the two.

First, the benefits of the two methods, as I have seen them expressed here. The timestamp method is flexible, and does not force us to choose a pre-meditated structure; the ZK can grow organically. The folgezettel, on the other hand, helps maintain some coherence in a sequence of notes, keeping the historical context in which notes were arrived at. But notes in a sequence are not intended to force a particular semantics.

One objection to Folgezettel is that it takes mental power to keep track of the ids in a sequence and it does not add anything beyond what links can anyway achieve; so cost, no benefit.

But there is benefit: I want to keep the local structure of a chain of thought while keeping the Zk "loosely coupled" that timestamps do.

So what I have done, shown with a screenshot from my webUI:

As you can see, I can see the local structure as a tree view, which helps my thinking. All my notes have timestamps, and that is the "id" of each note. But beyond that, the title begins with the folgezettel, and I have a library that allows me to say things like "make a child note here" (if I am at note 7.1a, and I already have 7.1a1 and 7.1a2, it will make a note with 7.1a3), or make a sibling note here, or start a new series (which may create 15.1 is I already have 14 series). Eufriction is all well and good, but I want to minimize friction, and this can be done using software.

I have been able to take notes quite rapidly and get a good bird's eye view of local structure, which is proving to be a powerful thinking tool, and this "integrated thinking environment" I am very happy with at the moment.

So there you have it, why I called it a false dichotomy: the two, timestamps and folgezettel, coexist harmoiniously in my zettelkasten.

I really liked the "gmail" analogy that @brborghi wheeled out on another thread, how tags are better than folders. To extend that analogy here, tags plus timestamps can simulate folders and we don't need folders. What the folgezettel gives us, though, is analogous to gmail threads: and without threads, gmail will be unusable for me.

Terry

With both timestamps and folgezettel, I can get the exact history of my zettelkasten's growth. They coexist harmoniously in my zettelkasten as well .

Looks like this:

Loni

I tried to use both. I tried without any hierarchical branching or codes, just by topics while they emerge from my notes, or with a code like the Antinet and I just can't follow the tracks.

It is way too heavy to lift for my cognition to track the sequences or to remember every code there and there, to choose some branch or an other. "Why here and not here?" or "why putting this note here if I don't have the "master" branch already plugged?"

I know, indexes are here to remember, cool thing.

I can't work with it. It leads me to confusion, to overcomplication, to anxiety. The dark side of the ZK. At the end, I did'nt work with my Zettelkasten at all.

I can make hierachical indexes. As i work with paper notecards, I can make physical drawers, boxes and dividers to keep some cards together. That's what I make for my workouts exercices after all. I also can make some structure notes from my cards, putting them on my desk and follow the tracks of my thoughts.

But for now, I don't want to get back to folgezettels. It's nice to see that it works for you, though.

amahabal

@Loni said:

It is way too heavy to lift for my cognition to track the sequences or to remember every code there and there, to choose some branch or an other. "Why here and not here?" or "why putting this note here if I don't have the "master" branch already plugged?"

I can't work with it. It leads me to confusion, to overcomplication, to anxiety. The dark side of the ZK. At the end, I did'nt work with my Zettelkasten at all.

I know what you are saying. Before I built more tooling for the folgezettel to be worthwhile, they were indeed stressful, as I capture in these series of notes. These notes relieved much of my stress.

Where to put a note was a perennial dilemma: and yet an answer satisfying to me is "it doesn't matter!". A little bit of local structure still helps (for example, to re-invoke the threads analogy, sometimes in email we keep answering in a thread, or sometimes we start another thread for a side discussion).

My specific flavor of sub-clinical OCD (now mostly behind me) was a need to know everything about everything, which has been professionally a boon in some ways, but which also has the potential to be debilitating. For example, I am a quasi-linguist but I am "merely" a trilingual, and I used to feel deeply guilty about not understanding more languages and not understanding any non-Indo-European language. Zk can indeed have a dark side for such individuals as "me a few years ago". I am glad that I now have a healthy benefit-to-cost ratio in Zk use, or so I delude myself.

Loni

@amahabal said:
Where to put a note was a perennial dilemma: and yet an answer satisfying to me is "it doesn't matter!"

Indeed. That's why I don't use Folgezettel. I just need a physical definitive adress to find my paper notecards, so chronological UID are perfect for me. Makes easier to do not ask myself if it is perfect and all.

Zk can indeed have a dark side for such individuals as "me a few years ago".

For anyone, I think. I have some specificities myself, but I think anyone can felt into some snares and get drawn to the darkside. Overcomplication, confusion, anxiety can happen to anyone

But if something works for you, that's the only thing that matters.

ZettelDistraction

Oops, wrong thread! I have combined keywords with timestamps these days. This allows for some grouping.

georgeraraujo

@Terry said:
With both timestamps and folgezettel, I can get the exact history of my zettelkasten's growth. They coexist harmoniously in my zettelkasten as well .

Looks like this:

Your graph shows beautifully how a single idea can give rise to multiple lines of thought that can themselves branch off. Visual evidence is very compelling.

A question: in case you add a link from G203-1A-2-2E to G203-1A-2-4, does it show in the graph? More generally, does the program show links between notes whose IDs are not Folgezettel-based and instead link to one another via Markdown/Wikilinks?

Andy

@amahabal said:

So there you have it, why I called it a false dichotomy: the two, timestamps and folgezettel, coexist harmoiniously in my zettelkasten.

If you haven't seen it, you may like an older discussion in which @argonsnorts showed a similar combination of timestamp UIDs and folgezettel: "Hierarchical Branched Note Taking and The Archive App (is topography important?)" (March 2020).

Soon after that discussion started, @Sascha published his post "Understanding Hierarchy by Translating Folgezettel and Structure Zettel" (April 2020).

@amahabal said:

I really liked the "gmail" analogy that @brborghi wheeled out on another thread, how tags are better than folders. To extend that analogy here, tags plus timestamps can simulate folders and we don't need folders. What the folgezettel gives us, though, is analogous to gmail threads: and without threads, gmail will be unusable for me.

By the way, the Breadcrumbs plugin for Obsidian provides interesting options for building and navigating structures analogous to Gmail threads, as you call it. See the Alternative Hierarchy Building section of the Breadcrumbs documentation. Even if you don't use Obsidian, it's an interesting plugin to study for structure ideas.

@georgeraraujo said:

A question: in case you add a link from G203-1A-2-2E to G203-1A-2-4, does it show in the graph? More generally, does the program show links between notes whose IDs are not Folgezettel-based and instead link to one another via Markdown/Wikilinks?

I haven't used @Terry's plugin (which was previously introduced in the forum here), but the Obsidian Zettelkasten Navigation README file on GitHub only mentions visualizing Luhmann-style IDs & Luhmann-style key word indexes, not wikilinks. Of course, visualizing wikilinks is not necessary because it's a plugin for Obsidian, which can already visualize wikilinks in the default graph view, not to mention other plugins.

It would be interesting to know if anyone uses both the Obsidian Zettelkasten Navigation plugin and the Breadcrumbs plugin?

The Obsidian Zettelkasten Navigation README file on GitHub asks:

The graph view, basing on linkages/references between notes, in some ways can represent the aspect of disorder of a zettelkasten. But what is the aspect of order?

Of course, the Luhmann-style IDs & Luhmann-style key word indexes that the Obsidian Zettelkasten Navigation plugin visualizes are not the only possible "aspects of order". There are also structure notes! And the Breadcrumbs plugin understands the structure in one type of structure note that it calls Hierarchy Notes. It would be very interesting if the Obsidian Zettelkasten Navigation plugin could also parse Breadcrumbs-style Hierarchy Notes, thereby also supporting a common type of structure note, which is another important "aspect of order".

EDIT: I corrected the link to the March 2020 forum discussion in my first paragraph.

georgeraraujo

@Andy said:
@georgeraraujo said:

A question: in case you add a link from G203-1A-2-2E to G203-1A-2-4, does it show in the graph? More generally, does the program show links between notes whose IDs are not Folgezettel-based and instead link to one another via Markdown/Wikilinks?

I haven't used @Terry's plugin, but the Obsidian Zettelkasten Navigation README file on GitHub only mentions visualizing Luhmann-style IDs & Luhmann-style key word indexes, not wikilinks. Of course, visualizing wikilinks is not necessary because it's a plugin for Obsidian, which can already visualize wikilinks in the default graph view, not to mention other plugins.

Ah, it's a plugin for Obsidian. Nice!

While Obsidian can already visualize wikilinks in the default graph view, for Zettelkasten I find @Terry's tree-like presentation to be more organized and easier to navigate. Obsidian's built-in default view can be confusing for this particular use case:

Andy

@georgeraraujo said:

While Obsidian can already visualize wikilinks in the default graph view, for Zettelkasten I find @Terry's tree-like presentation to be more organized and easier to navigate. Obsidian's built-in default view can be confusing for this particular use case:

Yes, that's exactly the rationale for the plugin as stated in the quotation above from the Obsidian Zettelkasten Navigation README file on GitHub: "The graph view, basing on linkages/references between notes, in some ways can represent the aspect of disorder"!

The Excalibrain plugin for Obsidian can provide a similar structure-based visualization in concert with the Breadcrumbs plugin, but not by parsing Luhmann-style IDs as in the Obsidian Zettelkasten Navigation plugin. So there are various ways to get alternative ordered views in Obsidian.

amahabal

@Andy said:

Soon after that discussion started, @Sascha published his post "Understanding Hierarchy by Translating Folgezettel and Structure Zettel" (April 2020).

Thanks, yes, I had read that post, and my sense was that @Sascha had taken a hard line against folgezettel, that they do not add anything beyond structure notes.

He ends that post with two questions, of which I will answer the first:

1. If you use the Folgezettel technique, what are your actual goals?

My goal is local structure (without imposing the anti-pattern of global structure). As I am working on some argument, the various pieces of it can be in a tree structure that sort of work like a structure note. Note two things are critical to my use here:

• I also have "real" structure notes. I can have as many of them as needed.
• Unlike Luhmann's "single tree" (as stated/implied by Sascha), I see what I have as an infinite number of trees. The series 2.* is quite independent of 3.*, although of course there can be and are ordinary links between the two.

Since moving to the new structure, I find that I am making notes far more atomic than before with less friction of needing to keep a map of this local area via a structure note. The local tree gives me such an automatically evolving structure (so less friction), without fencing me in, since I can always start new trees, always add structure notes, and so forth.

Perhaps what facilitated this was the suggestion from Bob Doto to use declarative sentences as note titles. These seem to fir better in a hierarchy, and maybe making it easier for the tree, by itself, to act as a poor man's version of a (local) structure note.

I don't have anything absolutely trustworthy to say about his second question, but do have some circumstantial data:

2. How do you measure your progress towards those goals?

I have been very productive with me note taking since moving to the new system, in terms of notes/day. Of course, this evidence is of limited value on its own, a dubious metric at best given the ever present possibility of the collector's fallacy, and my definite feeling of "it has been much easier" isn't quite measurable.

Andy

@amahabal said:

Thanks, yes, I had read that post, and my sense was that @Sascha had taken a hard line against folgezettel, that they do not add anything beyond structure notes.

Thanks—I think Sascha's right that there is no less order in a structure note than in folgezettel, but he's wrong that folgezettel adds nothing beyond structure notes, insofar as folgezettel provides a specified order (non-alphabetical and non-chronological) in an automated simple list of files in, e.g. standard file browser/manager software.

My goal is local structure (without imposing the anti-pattern of global structure). As I am working on some argument, the various pieces of it can be in a tree structure that sort of work like a structure note. Note two things are critical to my use here:

• I also have "real" structure notes. I can have as many of them as needed.
• Unlike Luhmann's "single tree" (as stated/implied by Sascha), I see what I have as an infinite number of trees. The series 2.* is quite independent of 3.*, although of course there can be and are ordinary links between the two.

Note that this local order can also be achieved with typed relationships (typed links), as in the Breadcrumbs plugin previously mentioned. Breadcrumbs has a few ways to view relationships: Views, Create Local Index, and Write Breadcrumbs to File. The Excalibrain plugin, as already mentioned, can also visualize such typed relationships.

The software examples that I'm citing rely on Obsidian, but the important point is the principle of typed relationships, which could be implemented by anyone with requisite programming skills. Typed relationships are in principle a way to achieve local order without folgezettel. Their strength is that they are more flexible than folgezettel; their weakness is that they do not automatically provide order in a simple list of files as folgezettel do.

Since moving to the new structure, I find that I am making notes far more atomic than before with less friction of needing to keep a map of this local area via a structure note. The local tree gives me such an automatically evolving structure (so less friction), without fencing me in, since I can always start new trees, always add structure notes, and so forth.

I find these same benefits in my use of typed relationships, which are my preferred solution for the local order outside of structure notes. But I understand why some people prefer folgezettel.

Perhaps what facilitated this was the suggestion from Bob Doto to use declarative sentences as note titles.

I agree that this is a good practice whether or not one uses folgezettel.

amahabal

@Andy said:

Note that this local order can also be achieved with typed relationships (typed links), as in the Breadcrumbs plugin previously mentioned. Breadcrumbs has a few ways to view relationships: Views, Create Local Index, and Write Breadcrumbs to File. The Excalibrain plugin, as already mentioned, can also visualize such typed relationships.

Thanks! Please help me understand what the set of all types are: it is "parent", "child", "sibling"? Or is there more? (Is "next" and "previous" the same as "next sibling", etc)?

If so, then I have most of these with the folgezettel except the ability to have multiple parents. And you are right, this can provide local structure.

When I create a note, my system knows the folgezettel id of the current note and knows the set of all ids I have in my system. If I wish to create a note with the title foo, and wish it to be the child of the current note, I just have to type - foo and it will pick the next available child id. If I want the next sibling, I do _ foo. A new tree is started with ^ foo. But, and this is critical, if I am at note 13.3a and want to add a child note of 13.3a2c without navigating to that note, I just have to type ~2c foo. I do not know how effortless creating new notes or links is with the plugins you mention, but it is effortless in my system now.

Curious: how frequently do you find yourself needing multiple parents of a single note? I can see the theoretical benefits, but I am hoping to get a sense of how often, in practice, you do so, and whether when that happens it is for "broad" notes vs something very deep and specific.

Andy

@amahabal said:

Thanks! Please help me understand what the set of all types are: it is "parent", "child", "sibling"? Or is there more? (Is "next" and "previous" the same as "next sibling", etc)?

Those three terms are common hierarchy terms that the Breadcrumbs plugin uses to refer to relative hierarchical placement (let's call it the tree structure), but you can define as many relationship schemas (called "Hierarchies" in Breadcrumbs) as you want that correspond to the tree structure.

Curious: how frequently do you find yourself needing multiple parents of a single note? I can see the theoretical benefits, but I am hoping to get a sense of how often, in practice, you do so, and whether when that happens it is for "broad" notes vs something very deep and specific.

I don't need multiple parents often. As I've said elsewhere, I use a schema that's similar to IBIS, and question is the type of note that needs multiple parents most often. (In strict IBIS, an issue/question is the one type of note that can respond to any other type of note.)

But what I had in mind when I referred to flexibility was mostly the ability to easily move a whole branch (a note and all its children) to a different place. With folgezettel you would have to change the Luhmann ID of every moved note. With typed relationships, you just change one relationship and you're done.

georgeraraujo

@Andy said:
The Excalibrain plugin for Obsidian can provide a similar structure-based visualization in concert with the Breadcrumbs plugin, but not by parsing Luhmann-style IDs as in the Obsidian Zettelkasten Navigation plugin. So there are various ways to get alternative ordered views in Obsidian.

I searched a bit and found the Link Tree plugin. The view it presents is close enough to what I had in mind:

Terry

About wikilinks

@georgeraraujo said:

A question: in case you add a link from G203-1A-2-2E to G203-1A-2-4, does it show in the graph? More generally, does the program show links between notes whose IDs are not Folgezettel-based and instead link to one another via Markdown/Wikilinks?

As @Andy mentioned:

visualizing wikilinks is not necessary because it's a plugin for Obsidian, which can already visualize wikilinks in the default graph view, not to mention other plugins.

There are many plugins have done a great job on visualizing wikilinks. So, a wiki network is not the scope of Zettelkasten Navigation plugin.

However, wikilinks is one of the important components of a zettelkasten. So, i created a local view in my plugin to visual one-level ininks and outlinks for the current open note. And there is also a close-relative graph in local viewto display the parent, siblings and sons for the current open note.

About multiple parents:

@amahabal said:

Curious: how frequently do you find yourself needing multiple parents of a single note? I can see the theoretical benefits, but I am hoping to get a sense of how often, in practice, you do so, and whether when that happens it is for "broad" notes vs something very deep and specific.

@Andy's answer:

I don't need multiple parents often. As I've said elsewhere, I use a schema that's similar to IBIS, and question is the type of note that needs multiple parents most often. (In strict IBIS, an issue/question is the one type of note that can respond to any other type of note.)
But what I had in mind when I referred to flexibility was mostly the ability to easily move a whole branch (a note and all its children) to a different place. With folgezettel you would have to change the Luhmann ID of every moved note. With typed relationships, you just change one relationship and you're done.

Zettelkasten Navigation plugin released a experimental feature "allow mutiple IDs(folgezettel)" recently. A zettel can be added to different branches by assinging new IDs. It means a zettel is allowed to have multiple parents with this feature. Demo

Terry

Here is another use case about "timestamps and folgezettel coexist harmoniously": interlinking nodes(in tree view) and daily note.

(Timestamps is the created time of my zettel. I use daily note in my vault.)

Above demo is using these features provided by Zettelkasten Navigation plugin:
1. node menu: you can add your custom commands to node menu.
2. uri: you can use uri to reveal a zettel in tree view(index-graph-view)

Terry

@Andy said:

Of course, the Luhmann-style IDs & Luhmann-style key word indexes that the Obsidian Zettelkasten Navigation plugin visualizes are not the only possible "aspects of order". There are also structure notes!

Yes. i totally agree. structure notes are "aspects of order" as well.

@Andy said:

And the Breadcrumbs plugin understands the structure in one type of structure note that it calls Hierarchy Notes. It would be very interesting if the Obsidian Zettelkasten Navigation plugin could also parse Breadcrumbs-style Hierarchy Notes, thereby also supporting a common type of structure note, which is another important "aspect of order".

I am not familiar with Breadcrumbs. I am not sure if my understanding of Hierarchy Notes is correct. But if you want to visualize headings and lists as a tree-like structure. I think some mindmap plugins have done a great job.

thanks for your suggestions anyway. I will think about it. Maybe Zettelkasten Navigation plugin can generate a mermaid graph-style tree view for sturcture notes in future.

Sascha

I try not to add too much to the discussion here, as most of my positions are already published. Just a few bullet points that I'd like to highlight:

• The general reason to create both structure notes and the folgezettel-tree is to create a correlate of space: Both aim to create a visually accessible whole in which we see the relationships of the parts. If you already created space with one of the methods, the task is accomplished, and you might increase the structural complexity of your Zettelkasten with little utilitarian benefit. In a way, it is similar to feature bloat of apps: Even if you try to ignore all the features, they are there and have their influence. This is the reason why the class of "distraction free editors" was born.
• One of the major tasks is to train your brain alongside the Zettelkasten. This familiarity is part of the causal mechanism how the Zettelkasten creates "the magic". The more complexity you add, the more cognitive load you introduce, increasing ambiguity which reduces familiarity. This is why I think that one should decide for one. Not because both can't co-exist on methodological principle, but because of added cognitive load. Keep in mind, that you want *as little surface level structure as possible to make the deep structure possible. Surface level structure is for example the id, folgezettel positioning, backlinks etc. Deep structure is for example the actual connection of one note containing the empirical evidence for the premise of the argument captured in another note. From experience with more and more people, I know that many struggle to even access the deep structure in the first place.
  • Take me for example: I feel very comfortable with the deep structure, since I am consciously dealing with it for 15 years (for many years this was almost all what I did). But I am very conservative in introducing more complexity on the level of surface level structure, because I have to protect my available cognitive capacity. Doing the actual knowledge work is hard enough.

I almost never spend time on maintaining anything in my Zettelkasten just to keep in working. Though my work is very complex, the short list of techniques is more than enough to make the knowledge work happen and the desired results achievable. I don't work on my Zettelkasten, but rather with it.