Over a year ago we had a long thread on the "Zettelkasten" system:
https://groups.google.com/g/leo-editor/c/TqiNdBfnEig To briefly reprise, a *zettelkasten* is a system for capturing and cross-linking of knowledge. The term can be translated as "card case", and the original - or at least the one that became somewhat well known - comprises a set of index cards, a group of file drawers to store them, and a way of numbering the cards so that they cross-refer to other cards. Each card (or "zettel") is expected to carry a short, narrowly focused, thought or essay-like paragraph about some topic. The system was written about by Niklas Luhmann, who apparently was wildly prolific as a writer and known for his deep knowledge of a number of fields of study. He credited his zettelkasen with much of his success, referring to it as a second brain or a very smart companion. See, e.g., "Communicating with Slip Boxes by Niklas Luhmann": http://luhmann.surge.sh/communicating-with-slip-boxes Luhmann had developed a way of numbering and cross-linking his cards that seems to have worked extraordinarily well for him. The thread on Google Groups was mostly concerned with whether Leo could be used for such a system, and how that would work. There are several software systems that claim to be designed for this purpose, but I didn't find any of them satisfactory, and it would generally have been hard to impossible to get your data back out in a usable form if you wanted to switch to another way of working. Eventually I distilled the points that had been discussed into a set of user requirements, and I realized that with a few simple scripts and a standard way of working, a zettelkasten system in Leo would be extremely easy and effective. One of the key points is to have a way to extract your data easily, which means working with a text format or something that can be converted to a text format easily. As you will see, that is quite simple. After all this, I got diverted and didn't do much with it until recently, a year and more later. I wanted to capture some genealogy/family history data and organize it somehow. So I have been working with the card-case system, and I've learned some practical things. This has led me to slightly change the scripts, and to settle on a way to format and use the cards. I think it's working really well, and I'd like to pass this experience along. I have attached the requirements I came up with along with some links to more material about this kind of system. In my next post I will talk about the card format and the scripts that make it all work. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/24f7f769-4207-43ac-af38-3ce5e902ecaan%40googlegroups.com.
<?xml version="1.0" encoding="utf-8"?> <!-- Created by Leo: http://leoeditor.com/leo_toc.html --> <leo_file xmlns:leo="http://leoeditor.com/namespaces/leo-python-editor/1.1"; > <leo_header file_format="2"/> <globals/> <preferences/> <find_panel_settings/> <vnodes> <v t="tom.20210617195453.2"><vh>Zettelkasten Requirements</vh> <v t="tom.20210617195528.1"><vh>Basic User Requirements</vh> <v t="tom.20210617195528.2"><vh>1. No Lockin</vh></v> <v t="tom.20210617195528.3"><vh>2. Text Files</vh></v> <v t="tom.20210617195528.4"><vh>3. Simple Section Demarkations</vh></v> <v t="tom.20210617195528.5"><vh>4. Unique Identification</vh></v> <v t="tom.20210617195528.6"><vh>5. Hierarchical Navigation</vh></v> <v t="tom.20210617195528.7"><vh>6. Link Navigation</vh></v> <v t="tom.20210617195528.8"><vh>7. Time Stamp</vh></v> <v t="tom.20210617195528.9"><vh>8. Tags</vh></v> <v t="tom.20210617195528.10"><vh>9. Backlinks</vh></v> <v t="tom.20210617195528.11"><vh>10. Display Styles</vh> <v t="tom.20210617195528.12"><vh>*Display Styles*</vh></v> </v> <v t="tom.20210617195528.13"><vh>11. Citations</vh></v> </v> </v> <v t="tom.20210617230826.1"><vh>References</vh></v> </vnodes> <tnodes> <t tx="tom.20210617195453.2"></t> <t tx="tom.20210617195528.1" __node_tags="635f5f6275696c74696e5f5f0a7365740a7100285d710158130000007a657474656c2f726571756972656d656e74737102617471035271042e"></t> <t tx="tom.20210617195528.10" _bklnk="7d71002858050000006c696e6b7371015d71022858010000005371035815000000546f6d502e32303230303230333133353933382e31710474710561580400000075726c7371065d7107752e"> **Requirement**: For every link to another note that is inserted into a note, the system must create a corresponding link in the target back to the first note. Alternatively, the linking system may be inherently bi-directional, such that backlinks occur automatically. **Discussion**: If the system exports data to text files, the backlinks must be included in the exported notes data. </t> <t tx="tom.20210617195528.11"> **Requirement**: Selected subsets of notes must be displayable in both a hierarchical display (where parent/child or sibling relationships exist) and a non-hierarchical display of associated notes. **Discussion**: A strength of the original zettelkasten paper system was that one was not forced into thinking about the notes as having any kind of a strict hierarchy. This feature must be preserved in the new system. The apparently hierarchical identity coding was mainly for locating notes in the note boxes. However, notes near each other were more likely to relate to each other. It would be possible to have parent/child relationship between notes that were not located near each other, but having them close together tends to make them more available when working on a subset of notes. **Requirement**: It must be possible to add additional types of displays besides a basic parent/child.style. **Discussion**: This should not be taken to imply that any arbitrary display idea should be easy or even feasible to implement. It is intended to indicate that other display styles than a straight parent/child hierarchical display will probably be found to be desirable, and that the system should make it possible to implement at least some kinds. </t> <t tx="tom.20210617195528.12">In Leo, the most obvious way to display subsets of notes would be to clone them and move the clones under a single organizing node. This collection could be ephemeral or permanent as the user desires. For a non-hierarchical display, the simplest way would be to have all the notes (or their clones) as siblings under a single organizing node. LeoVue is one system that makes possible coordination with browser-based displays, some of which can be be interactive so that actions in the browser can be reflected back to the Leo file. There are probably other such systems. This is one way in which new display kinds could be created, ones that Leo's panes and display mechanisms may be less suited for. The cost, aside from the effort of implementation, would be that a web server would have to be involved, most likely on the user's computer. However, such relatively simple personal servers are not hard to install and get working. </t> <t tx="tom.20210617195528.13">**Requirement**: It must be possible to maintain a collection of citations to source material. It must be possible for a zettel-box note to reference any of these citations. It must be possible to retrieve the text of the citation when desired. **Definition**: "Citation" means a standardized means of reference to a specific source material. **Discussion**: An academic citation includes title and and publication data in a standardized form. This is the main kind of citation envisioned here. Possibly, a citation could also be a URL to an on-line resource.</t> <t tx="tom.20210617195528.2" _bklnk="7d71002858050000006c696e6b7371015d71022858010000004471035815000000546f6d502e32303230303231343134333335392e31710474710561580400000075726c7371065d7107752e"> **Requirement**: The notes data must be in such a form that they may be transferred to another notes system (even a paper one) without losing any essential data. **Discussion**: If the note-keeper decides to change to another notes mangement system, the data must be useful outside the Zettel-box, so that months or years of research not be lost. What is the most basic alternative system? That would probably be a full-text search system. Another basic system would be a paper system like the original zettelkasten. These needs lead to the next requirement. </t> <t tx="tom.20210617195528.3" _bklnk="7d71002858050000006c696e6b7371015d71022858010000004471035815000000546f6d502e32303230303231343134333632302e31710474710561580400000075726c7371065d7107752e"> **Requirement**: The zettel-box notes must be in a text format. They may be one note per file, all notes in one file, or a combination. Alternatively, the system must be able to export such files with no loss of data. **Definition**: "Text format" includes slightly structured text-based formats like Markdown or ReStructured Text. It excludes more complex formats such as XML. The intent is that the note files must be easily readable by a person. **Discussion**: Using one file per note seems to be the simplest way to emulate the original paper-based system, which had one card per note. However, a larger file could be used if there is simple way to extract or recognize individual notes. This would allow a computer program to separate the individual note if needed. </t> <t tx="tom.20210617195528.4" _bklnk="7d71002858050000006c696e6b7371015d71022858010000004471035815000000546f6d502e32303230303231343134333735342e31710474710561580400000075726c7371065d7107752e"> **Requirement**: If a note needs identified sections, the section demarkations must be easy to type, easy to read, and easy to parse by computer. **Discussion**: An identified section could be a URL, a group of references to other notes, a tag or indexing aid, a citation list, etc. </t> <t tx="tom.20210617195528.5" _bklnk="7d71002858050000006c696e6b7371015d71022858010000004471035815000000546f6d502e32303230303231343134343535392e31710474710561580400000075726c7371065d7107752e"> **Requirement**: Each note must be uniquely identifiable, so that it can be referenced by other notes. </t> <t tx="tom.20210617195528.6" _bklnk="7d71002858050000006c696e6b7371015d71022858010000004471035815000000546f6d502e32303230303231343134343733392e31710474710561580400000075726c7371065d7107752e" __node_tags="635f5f6275696c74696e5f5f0a7365740a7100285d7101580a0000006e617669676174696f6e7102617471035271042e"> **Requirements**: The system must support a flexible system for identifying notes that have parent/child or sibling relationships with other notes. These relationships must be included in the text files or the exported data. It must be possible to also have notes that do not possess a hierarchical designation (possibly as a temporary characteristic). **Ref**: see `The Zettelkasten Method <https://www.lesswrong.com/posts/NfdHG6oHBJ8Qxc26s/the-zettelkasten-method-1#Card_Layout>`_. **Discussion**: This was a key characteristic of the original Zettelkasten system. Basically it amounted to each note having an optional parent-child or sibling relationship with certain related notes. In the paper system, a note was decorated with an indexing expression like "1.2.1.4" or (a more concise form) "1a1d". This designation let the notekeeper file and find closely related note cards. The system needs to be flexible because it is likely that newer notes will be created to elaborate on older ones, so insertions will be required. In the original system, these designations acted as unique card identifiers. **Note**: All notes must be findable whether or not they contain any links to any other parent/child or sibling notes. </t> <t tx="tom.20210617195528.7" _bklnk="7d71002858050000006c696e6b7371015d7102282858010000004471035815000000546f6d502e32303230303231343134353132342e3171047471052868035815000000546f6d502e32303230303230333231303230332e31710674710765580400000075726c7371085d7109752e"> **Requirement**: It must be possible to link a note to other notes by reference. **Discussion**: This implies that each note must have a unique identifier that does not change. This was another essential property of the original paper-based zettelkasten system. It is this linking that seems to have promoted the system's legendary reputation for enhancing creativity. In the original paper system, the indexing expression served as the identifier. </t> <t tx="tom.20210617195528.8" _bklnk="7d71002858050000006c696e6b7371015d71022858010000004471035815000000546f6d502e32303230303231343134353730392e31710474710561580400000075726c7371065d7107752e"> **Requirement**: Each note must be able to have an optional timestamp. **Discussion**: A number of people have written that having a timestamp is helpful in reconstructing the context of recent work, since the most recent notes most likely represent work that was recently done. It is currently unclear about whether only a creation date would be enough, or whether a last-modified date will also be helpful. It the interest of simplicity in a potential move to hand-created or paper notes, a single date would be better. </t> <t tx="tom.20210617195528.9" _bklnk="7d71002858050000006c696e6b7371015d71022858010000004471035815000000546f6d502e32303230303231343138353132332e31710474710561580400000075726c7371065d7107752e"> **Requirement**: The system must be capable of optionally attaching one or more "tags" to any note. Tags must be easy to create, delete, and attach. **Definition**: A tag means a property represented by a name (a string). **Discussion**: Tags serve primarily as a filtering mechanism, to help identify notes in a general area of interest. </t> <t tx="tom.20210617230826.1">:id: TomP.20200225095046.1 :timestamp: 02/25/2020 09:50:59 References for zettelkasten design, use, and benefits. `Communicating with Slip Boxes by Niklas Luhmann <http://luhmann.surge.sh/communicating-with-slip-boxes>`_ `Luhmann on Learning How to Read <https://takingnotenow.blogspot.de/2007/12/luhmann-on-learning-how-to-read.html>`_ `Use Zettelkasten Method for More Scientific Note Taking <https://www.seanlawson.net/2018/02/use-zettelkasten-method-scientific-note-taking/>`_ `Manage Citations for a Zettelkasten <https://zettelkasten.de/posts/bibliography-zettelkasten/>`_ `The Zettelkasten Method <https://www.lesswrong.com/posts/NfdHG6oHBJ8Qxc26s/the-zettelkasten-method-1>`_ `How to take smart notes (Ahrens, 2017) <https://www.lesswrong.com/posts/T382CLwAjsy3fmecf/how-to-take-smart-notes-ahrens-2017>`_ `Three Layers of Evidence <https://zettelkasten.de/posts/layers-of-evidence/>`_ `The Barbell Method of Reading <https://zettelkasten.de/posts/barbell-method-reading/>`_ `Luhmann’s Zettelkasten — A Productivity Tool That Works Like Your Brain <https://emvi.com/blog/luhmanns-zettelkasten-a-productivity-tool-that-works-like-your-brain-N9Gd2G4aPv>`_ </t> </tnodes> </leo_file>
