Using Cartography as a Metaphor for Investigating the Great Folgezettel Debate
As a novice Zettler introduced to the method via the Cortex podcast, I’ve been taking the last year or so to build up the foundations of a useful archive. I’ve come to an inflection point in the management of my archive, as I’ve done a lot of collecting and not a lot of assimilating, linking, etc. Of course, at this new stage, it’s only natural that I’ve stumbled upon the Great Folgezettel Debate. After going on a deep dive in the forums for the past week, I’ve come to the point where I’d like to start weighing the tradeoffs between the two most prevalent organizational techniques I see discussed here: Folgezettel and Structure Zettel (Structure Notes? Can someone disambiguate the proper terminology for me?).
While I think I have a feel for where I’ll land at the end of this, I want to float my ideas in the forums first to see how they land.
Topography of a Zettelkasten
I’m a big fan of laying some foundations before discussing anything, so I’d like to begin with a deeper investigation of a metaphor I’ve seen pop up when Folgezettel are discussed: topography.
I first saw the discussion of “topography” in this post, but have seen both implicit and explicit discussions about the idea of the topography of a Zettelkasten all throughout the forums (see here for example). Instinctually, I love this term in the context of Zettelkasten, and at the beginning of this post I want to call for help crystallizing a definition for what we mean when we talk about topography. My working definition:
Topography of a Zettelkasten := The arrangement of connections that exist in an archive.
I would expand on this to say that the Topography of a Zettelkasten “mirrors” the Topography of all possible connections within a Zettelkasten. In other words, the connections that are in our Zettelkasten are a subset/selection of all the possible connections that could exist (which seems trivial to state). Again, our practical, real Zettelkasten is an image of this "Maximal" slip box with all possible connections, but not an exact image – in fact, an exact image would not be useful to us...knowing that every note can be connected to every other note for some reason would not be useful in practicality, but I digress. So, for another working definition:
Topography of Knowledge in a Zettelkasten := The arrangement of connections that exist in a "Maximal" archive.
Cartography as a Metaphor
Before moving on, it's worthwhile to note that the language of "mapping" out the knowledge in a Zettelkasten is already common (see here and here, for example). Personally, I’ve come to find the idea of mapping out knowledge to be more apt than I’d initially realized.
To play with the metaphor a bit, if there is a Topography of Knowledge in our Zettelkasten, then it makes sense that we should explore that Topography and selectively map out the connections the Topography contains for our use. In this case, our existing Zettelkasten is the map that we are constructing of the knowledge in the Maximal Zettelkasten.
If we’re making maps, that makes us cartographers. As such, I propose we can use cartographical language when discussing our ZK:
Here are the “fundamental objectives of traditional cartography” (via Wikipedia):
- Map Editing: “Select traits of the object to be mapped.”
- Generalization: “Eliminate characteristics of the mapped object that are not relevant to the map’s purpose” (see above) and “reduce the complexity of the characteristics that will be mapped.”
- Map Design: “Orchestrate the elements of the map to best convey its message.”
- Map Projection: “Represent the terrain of the mapped object on flat media.”
Here’s how they manifest in a ZK:
- ZK "map editing": We must select the traits we are interested in mapping. Of course, as @sfast notes, anything can be related to anything else (i.e. being “too creative” when making connections may not be useful), but it is our selection of interesting traits that makes our Zettelkasten useful to us based on the "comparative schema" we bring to the slip-box at any given time, as Luhmann writes about. I suggest our filter is simply "features/connections we find interesting,” which (again) seems trivial to state.
- ZK "generalization": We act upon the traits we've chosen in the "map editing" phase and only comparatively “file” (whether it be using Folgezettel, Structure Zettel, or something else) our notes selectively, placing them in contexts that are interesting or useful for us to continue lines of thought in our ZK ( @ethomasv covers this well here). We must also work to reduce the complexity of the things we do map (and we do this by choosing key features to focus on like topics, projects, curiosity, etc.).
These cartographical goals for our Zettelkasten cover the first two fundamental objectives of traditional cartography; they make up the foundation of ZK exploration: we comparatively file our notes, inherently using a comparative schema to place the note in one or more relevant contexts across the span of our archive. We are discovering connections as we traverse the notes in our archive.
We’ll assume here that we don’t make connections that aren’t useful to us (on an infinite timescale we could always make meaning of all the relationships established in our ZK), but the important takeaway is that editing and generalization are covered by the simple act of placing a note in the archive and settling it in a context, possibly via Folgezettel or Structure Zettel – but which method should we choose?
For the remaining two cartographical goals:
- ZK "map design": This, I propose, is the heart of the great Folgezettel debate. The question is: how do we orchestrate all of the elements above (the selected connections to be mapped) in a way that allows the Zettelkasten to serve as a "thought partner?” So far, the most popular methods of achieving this have been through direct links and either Folgezettel (or Folgezettel-like structures) or Structure Notes.
- ZK “map projection”: Deciding how to project our Topography onto a 2D space is what I see as a missing key to the Folgezettel debate. The similarities strike me here: we are literally projecting the complex Topography of our ZK into a 2D space: the text editor that’s on our screen. I think this similarity has been most vigorously alluded to by those who have been the largest advocates for Folgezettel, such as @pseudoevagrius and @argonsnorts , but I don't know of anywhere that has explicitly stated that the community should discuss how we see and traverse our knowledge Topography. (Maybe @Sociopoetic , our resident cartographer, has thoughts?)
A small note: while many of these goals seem to intermingle in their means and ends, I do think it’s especially important to note that it seems like map projection is a part of map design.
Prototyping an Archive with Three Different Structural Models
So, if our focus is on design, let’s play with some prototyping. In my exploration of The Great Folgezettel Debate, I made three archives that contain the same notes and approximately the same connections: one with Folgezettel titles, one with Folgezettel implemented using forwards-links, and one with Structure Zettel. I did not use time-based UIDs, as it wasn’t necessary for the scope of this project. I built these archives in Obsidian and visualized them using their graph tools. (I’ll also say that the archive is far from being an exemplary one. This is something that is truly a prototype for prototyping’s sake.)
(Download link for the 3 archives)
Here are the results:
Structure Zettel
Folgezettel implemented using forwards links
Folgezettel
Preliminarily, I would say that the local graph views are most useful in both Folgezettel conditions. In contrast, the global graph visualizations are most useful in the Structure Zettel and “forwards link” conditions. Of course, the list view is most useful in the Luhmannesque Folgezettel condition.
The feeling I get when using the archives to traverse the connections they contain is that Structure Zettel form a kind of “top-down” bird’s eye view. Knowledge is more obviously hierarchical and the structure feels most apt for constructing patterns and knowledge. It is very easy to look at the text of a Structure Zettel and follow a condensed line of thinking, the same way it’s easy to route from one city to another using a map.
When using both Folgezettel techniques to traverse, it feels like the Folgezettel form an on-the-ground “street view.” Knowledge, in this case, is more detailed and rich and it’s easier to see what a “next step” might entail as far as knowledge creation, argumentation, writing, etc. goes, the same way it’s easier to make a decision about what direction to turn when you’re on the ground, observing the environment at a particular location.
Closing
This is my first post in the forums and I have to say that it’s intimidating to jump into a conversation in such a committed, intelligent, and passionate community. I’m not sure if this metaphor is useful at all to you all, but I personally found it quite enlightening to have an apples-to-apples comparison of the different structural techniques I’ve been studying now for about a week.
Please, please let me know your thoughts and let me know if there’s anything I can clarify!
Edit @ctietze after featuring this on the blog: If you want to experiment with the data yourself, Austin released the benchmark notes on GitHub.
Howdy, Stranger!
Comments
Great post and interesting on cartography metaphor.
However, I think a better diagram of what a Folgezettel looks like comes from Luhmann’s actual archive. It’s essentially massive chainlinked tree-like structures similar to these (taken from archive):
Scott P. Scheper
Website | Twitter | Reddit | YouTube
This is true, elsewhere I have suggested that some network researchers use embeddings of networks into the hyperbolic plane http://personal.colby.edu/~sataylor/teaching/S14/MA314/ComplexNetworks.pdf
Not all networks should be visualized this way, but it is a popular approach.
That sounds fair.
I believe this is correct. The structure note is a synthetic technique. The patterns are imposed from the outside at the time of addition. The addition of a structure note to a ZK may bring with it as many Zettels as there are links in the structure note. It can obviously degenerate into the Folgezettel technique, if the structure note refers to the pre-existing node (or nodes) that would have been encoded in the ID, had Folgezettel been used. To rule out trivial cases, there should be an average lower bound on the number of nodes when developing a network based on structure notes.
This is an excellent analogy. There is a distinguished spanning tree (or graph) in the case of Folgezettel, consisting of the paths back to the root of each component. I suggest locating those predecessors in https://github.com/flengyel/Zettel. (I will probably simplify this).
It would facilitate the discussion to thicken the edges of the distinguished spanning tree. My efforts to convince anyone that it exists have been unsuccessful so far. Diagrams would help.
In the case of structure notes, in general, there is also spanning graph, but since the predecessors aren't explicitly called out (as they are in https://github.com/flengyel/Zettel), which spanning tree one chooses may not reflect the order of notes at the time they were added.
Thank you. I look forward to your further thoughts on this.
GitHub. Erdős #2. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Alter ego: Erel Dogg (not the first). CC BY-SA 4.0.
I used to write "Structure Notes". I then asked what the communities likes better. "Structure Zettel" got the majority vote. I started to retrain myself. The community continued to (mostly) write "Structure Notes". I worked through this betrayal. Now, "Structure Note" seems to be the convention with few exeptions. The Zettel Police remains silent on this issue even though I pressed charges.
I am a Zettler
Hey Scott! Happy to see you join the forums. I’ve been following your work over on YouTube.
That said, I am familiar with your argument that trees are the best metaphor for thinking about how to organize an archive, especially a physical one1. In this regard, I agree – a tree is a great metaphor, especially for someone like me with a background in computer science!
That said, the point that I'm making is that there is not a single "correct" representation. In fact, to the contrary, I think that different visualizations (and different manifestations, including physical) bring different strengths to an archive. This post wasn't making an argument for the best representation of a Zettelkasten; rather, it was advocating a toolset for investigating the strengths and weaknesses of different representations.
I'm also familiar that you have written "that the most powerful systems have tree-like properties!" ↩︎
@ZettelDistraction, so happy to see you reply. (I was secretly hoping you'd catch this post and give me some food for thought!)
I have seen you make this argument, thought I haven't dug into it yet. While I do love some good math, my higher-level math skills are relatively limited, so it may take me some time to grasp what the implications of this are. Do you have any pointers about where I might start my understanding?
When you talk about "degeneration" into Folgezettel, do you mean that Structure Notes inherently encode more information, since they have more flexibility for ordering, metadata, etc.? I feel like I might be misunderstanding you.
Sorry to ask so many clarifying questions here, but what I hear you saying is that Structure Notes, to be useful, should, on average, have a minimum number of notes? Again, my mathematical literacy isn't perfect.
These resources are fantastic. I will make use of them when I have a chance! Thank you!
Structure Note it is, then. It's good you have a stance on this, otherwise I may have fallen into the trap of being charged as well 😦 Just to cover up my tracks now...
Hello @iamaustinha! I do enjoy a good cartography metaphor, so thanks for pinging me. Before giving my thoughts on "projection" as we might want to explore it here, I'd like to offer a few thoughts on topology as a cartographic idea.
Essentially, a map will represent relationships between objects in a visual way. As alluded to above, not every map will have every data layer (just as our ZK won't have everything). For example, a street map probably won't show elevation (even for a hilly town). But a street map for cyclists might, because hills are useful data when planning a cycling route. So if we are to map our knowledge(s) in a ZK, it's unlikely that we should expect to map everything, even in some of the graphs offered above. As a rule of thumb, too much on a single map is noise. We should instead be interested in the signals we're sharing. In that sense, I'm not sure that having a comprehensive map (or topology) of an entire ZK will yield useful results -- but a partial map of our knowledge, maybe a map of everything in a specific family of tags, will no doubt illustrate landscapes of knowledge in new ways.
Here's something from one of my Zettel, on topology in GIS:
In our case, an "object" can be Zettel, "computational demands" is the thinking that feeds a ZK, and "analyses" are whatever we produce from the ZK (such as a thesis). As such, our topology isn't only Structure Zettel, but the links themselves. The mapping comes from understanding the links, not forcing them or plotting every one. Nevertheless, in constructing our topologies (making links), we can analyze those connections. In my view, analyzing the connections (following the links, producing new insights) is what makes writing from a ZK fruitful and, equally important, keeps the collector's fallacy in check.
A corollary to the above: in computerized mapping (GIS), data topologies are spreadsheets that list relationships. In some cases this is remarkably explicit, such as a table with a list of polygons and columns for the polygon to the east, west, etc. These tables are less computationally intensive than redundantly including information on each polygon border each time -- analogously, atomic notes with links are easier to parse than complex, long, multifaceted notes. The goal of the topology is to "wayfind" in the data.
Projections. In cartography, projections are classified by what information they maintain: preserving distance, area, or shape, for example. The projection doesn't change the topology but does change how data is visualized, and always at some cost (i.e., don't estimate distances using Mercator Projection, especially farther from the equator). Metaphorically, this could go two ways: if you're meaning that you want to visualize your ZK, then yes, different choices in visualizing (call those choices "projections" perhaps) will trade some objectives for others. However, if I understand the original intent of your question, you're considering how to navigate a ZK or its topology. I'm reminded of this note of mine, where text wasn't the best means to link together multiple other notes. But frankly, I wouldn't call this a projection, I'd call this an explicit topology (where other structure notes that are simple lists would be an implicit topology).
tl;dr: Any map shouldn't include everything. Good linking and good topology will make use of a ZK more fruitful and easier to navigate. Not all structure notes need to be lists, anyway, especially if we want to diagram those structures (and sometimes, we should make topologies very visually explicit). All this said, mapping is a useful metaphor for topologies for a ZK. Humans are sense making creatures, and the ultimate goal here should be to make sense of our data -- transforming it into knowledge. Let's not get lost in the 1:1 correspondence of the metaphor if isn't useful.
Lloyd, Christopher D. (2010) Spatial Data Analysis: An Introduction for GIS Users. Oxford: Oxford University Press. ↩︎
I'll need to get back to you about the background on these embeddings of graphs. (It looks to me that obsidian, logseq, zettlr use a library such as d3 to do this, and leave it at that.)
By the way, I think you may want to refer to graph embeddings in 2D as opposed to map projections.
Consider the structure note of @Sociopoetic in the previous comment. This is probably the best illustration of the technique I've seen. The structure note is a directed diagram illustrating typical steps that go into spatial modeling with applications to various earth system models, etc. If this Zettel had one or two links, there would not be much to distinguish it from a routine Zettel. (Maybe "degeneration" was a bad choice of words. I mean that structure notes with few outgoing links have little to distinguish themselves on the outside (forgetting about their content) from other Zettel. I wasn't drawing a distinction between them and Folgezettel.)
There is another point: cartography is an ancient subject. There are established practices and connections with geophysical and computational sciences that give a diagram like this authority.
I'm inclined to think structure notes work better for established subjects that have their own Wissenschaft, than for less established subjects.
Or I can invent outlines and categories out of thin air. Perhaps that's unfair...
Not necessarily to be useful, but to distinguish them by degree from other Zetteln. You had displays of various networks. What distinguishes a structure note in such a diagram from a non structure note? At best it looks like the out-degree.
Perhaps setting some minimum out-degree is less helpful. I had in mind computer experiments for attaching nodes to a Zettel network following simple rules. Over time, with computer simulations, one would see how such networks develop. It's still not clear to me, how to detect a "critical mass." (@taurusnoises points out that, outside of Germany, there probably aren't that many Zettelkasten that have reached critical mass. It's too new.)
As far as I can tell, the characteristic property of a Luhmann-esque network with Folgezettel is the presence of a distinguished spanning tree that records the order in which notes are inserted into the Zettelkasten. There may be other links between notes internally, but this spanning tree is what should be emphasized in network diagrams of Zettelkasten with Folgezttel --at least if I am correct. [there can be several trees if there are several disconnected components, not including internal links, but the case of one component is sufficient to convey the idea] How would you represent this? One obvious way is to make the edges of the spanning tree thicker than other links.
Then one could see at a glance what the Folgezttel IDs give you: a mnemonic device for visualizing the network, analogous to the locations of a memory palace, and for adding notes to the ZK (the IDs in this case have some semantic meaning). @taurusnoises mentions this. I'd like to know how his system is implemented. I don't see how timestamps serve the mnemonic function of Folgezttel IDs as easily. *
It would be helpful if one of the scholars at Universitat Bielefeld would weigh in on the visualization and mnemonic aspect of Folgezttel.
* This gives me the idea to replace Zettlr's ID regular expression (\d{14) with one that could be either a timestamp generated by %Y%D%M%h%m%s and matching the disjunction of (\d{14}) and some other regular expression for Folgezttel. This second expression is constrained by the need to avoid patterns likely to occur within notes. The first expression would maintain backwards compatibility, the second would encode a hint about the content. Also the timestamp generation pattern would be the default filename. The id could change, but the filename would still be a time stamp (or one could force them to be equal). I gave up on my "time stamp Folgezttel re-identification project" at this point, but I didn't have a mechanism to ensure backwards compatibility.
Thank you. I have cut some of it, and have attempted to resolve inconsistencies.
GitHub. Erdős #2. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Alter ego: Erel Dogg (not the first). CC BY-SA 4.0.
Nope. The structure on Structure Notes develop bottom up the majority of time. It is up to the Zettler if he chooses to use pre-formulated patterns.
The organic growth of structure notes is so strong that they even break templates if you work on them long enough.
(See this for illustration)
I am a Zettler
It definitely has that function for me. It's also how I bridge the tactility of the physical zettel object with the itchy pixels of digital. It just feels right at the end of the day. And, being GenX, I am inherently distrusting of a search bar retrieving my notes for me. I wanna see them stacked, relating. I wanna get side-tracked, etc. Search feels like I'm on the phone making my way through an automated system. But, people swear by it, sooo...🤷🏻♂️
Happy to show the implementation, though it's just a homegrown version of your basic 1A1b etc. Nothing fancy. The numbers just run on and on if need be.
I second this point. "Projection" is a very specific term for people working with geographic data. Graphs (in this mathematical sense especially) are also an elegant way to represent topologies. I attempted above to make this point about not using "map projections" in this way, and I think @ZettelDistraction said it better.
The diagram serves as a structure note for a specific kind of process. Moreover, the diagram isn't my original work, but using it as a template for a structure note is. And, the cartography note linked to in my above structure note is itself a structure note. The above note was full enough that including all of the links to cartographic subjects would be too numerous to be useful. I point this out in the service of another idea: by linking these structure notes, I have a navigable topology of the portion of my ZK devoted to GIS, while also making sensible divisions between different kinds of "established practices."
I know that's just my example, but I hope it's of benefit when considering the metaphors and visualizations we use when discussing Structure Notes.
Funny. If you're referring to my templates, then there is no reason that you couldn't have structure notes in the body of the Zettel. They won't break.
But that raises a good point: I now think "Folgezettel versus Structure Notes" is a false dichotomy.
I doubt that the term "structure note" is sufficiently well defined--it seems to come down to "a note with a lot of links" or a table or tree or matrix of links, or something topologically equivalent to this. (I'm not going to argue against them--I just don't see them as a reason to argue against Folgezettel.)
What prevents you from having both? Absolutely nothing. The argumentation against Folgezettel amounts to arguing against mnemonics in identifiers for visualizing the spanning tree. It's like arguing against memory palaces.
Sascha, I'm not throwing in the towel yet. I have a better idea.
Backwards compatible Folgezettel IDs in Zettlr
In Zettlr, filenames are generated with a Linux date-like syntax: %Y%M%S%h%m%s. By default IDs have the form \d{14}.md. What you could do is create a backwards compatible JavaScript regex say with at least 14 characters, to avoid matching most strings that arise in practice. Here's my solution: (\w{14,}). And here's how to do it in Zettlr:
In case the graphic is unreadable, the Markdown is
# a1_202202221123 Backwards compatible Folgezettel IDs in Zettlr
CONTEXT [[20211021195316]] Folgezettel Formalized
#folgezettel #zettlr #regex
Note: filenames and Zettel IDs will continue to be generated using the "Pattern used to generate new IDS." However, it is now possible to modify the ID using characters from the set [a-zA-Z0-9_] and Zettlr will continue to find them. To ensure that Zettlr finds these IDs, IDs should appear before anything else that might match (\w{14,}), e.g., at the first H1 header. By default, the filename of the Zettel will be the timestamp as before, but can be renamed to ID.md with ctrl-R. The ID a1_202202221123 is an example. The underscore is used to separate the Folgezettel portion from the generated timestamp.
GitHub. Erdős #2. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Alter ego: Erel Dogg (not the first). CC BY-SA 4.0.
@ZettelDistraction
Totally agree. New use-cases for fz allow fz and structure notes to be complementary rather than substitutions for one another (if a person wants to use both, which is very easy to do. Like, very easy. You just, well, do it!)
Ah, no, I am not referring to your templates since your template relates to what I call the "exterior form". I mean templates that relate to the "interior form" which governs the body of the note.
On the exterior, it is.
The argument is not against Folgezettel. It is against the current argumentation for Folgezettel.
(1) Nothing on the level of the exterior.
(2) One of the core benefits of having well-groomed Structure Notes is to have some kind of memory palace. (Structure Notes could be seen as rooms in a Dungeon Crawler)
I think there are some users that combined both in the same manner like you did.
So, they are compatible empirically.
I am a Zettler
UPDATE: the replacement regex for the default ID regular expression
(\d{14})I now use is(\d\w{13,}). This is for two reasons. First, to prevent Zettlr's ID highlighting algorithm from highlighting words with 14 or more characters such as 'implementation'. Second, so that IDs begin with at least one digit. (Luhmann's IDs began with a digit.)I'll say something about how these IDs work in conjunction with the template I use, to blunt an objection.
The term "exterior form" appears nowhere else within the zettelkasten.de site
and likewise for the term "interior form":
-- a fortiori, neither "exterior form" nor "interior form" have appeared before in the zettelkasten.de site in discussions of Folgezettel.
However, the intent is clear enough: the IDs I have started using, for example, 3a1p5_22020302 etc., will tell you something about the place of the note in the network (the "exterior form"). Specifically, the ID will tell you the path to the root within the distinguished spanning tree of the ZK network, and it will tell you that the note with this ID (reading 3a1p5_... from right to left) is the fifth note (the 5 before the underscore) of a sequence starting with note 3a1p1_... which itself was a comment on 3a1p, which was the 16th note in a sequence starting with 3a1a, and so on. I use 3 as a (rough) category number. So much for the "exterior form."
The implication (a philosopher of language might call it an "implicature") is that I have missed the deeper "interior form" (naturally), which refers to the context that presumably only a structure note can provide. However, I use these combined IDs in conjunction with a template which has a CONTEXT field, whose purpose is to provide at least some of the context --the profound "interior form"--that somehow lies beyond the reach of the superficial template, precisely for this reason. For example
In this case, the Folgezettel part of the ID is to the left of the underscore does some work to expose the "exterior form" and the Zettel title to the right provides some of the context--the "interior form"--that might be missing if I were confining myself only to Folgezettel. And of course, none of this prevents the template from being used in a structure note.
As for
I was aware of them, but they didn't meet my needs and it wasn't clear how to operationalize them. For now, I'll add some of these remarks about Zettlr ID configuration to my github site and leave it at that for a while.
GitHub. Erdős #2. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Alter ego: Erel Dogg (not the first). CC BY-SA 4.0.
No, it didn't. The article The Two Forms of a Zettel is a starter to think about that but it is somewhat outdated and needs extensive editing. It is just good enough to start this train of thought.
I don't really see a difference from your context field in which you provide links by ID and title and the Folgezettel in which the context is provided by surounding notes that provide the same.
So, what is the difference?
In which way weren't they sufficient?
I am a Zettler
Since today, we feature this post on the blog with an additional link to the source notes.
@iamaustinha shared the notes that produced the graphs on GitHub: https://github.com/austinha/zettelkasten-cartography/
I went ahead and added a link to the original post, too, so it's consistent with the blog.
Thanks again for this piece!
Author at Zettelkasten.de • https://christiantietze.de/
Honored to have this shared on the blog! A note here that, as @ctietze notes, the branch method on GitHub may be a little hard to navigate for those unfamiliar with git – and I promise I'll update the repo to better navigate for novice users at a later date when I have some time.
Also, I promise I'm working on some responses to the great comments here, just need some rumination time