Tips on taking notes - 2
In my last post, I mentioned that the core of the Zettelkasten [ZK] system is the use of links between notes. I used a “language-games” note to illustrate how to access any note from and index file following different pathways. In passing, though, I made reference to “sub indices”, but did not elaborate on the concept. I want to remedy this here to pre-emptively answer a possible objection.
Since our filenames are unique strings of numbers that do not tell us anything about the note’s contents, we need an entry-point to access any note. So we begin with an index file. In my personal implementation of ZK, the index initially contained a list of links to a bunch of miscellaneous notes. Some were about philosophy, others about mathematics, Linux, literature, etc. Naturally, some notes were more interrelated because of their subject-matter, and their links were grouped together and separated from the rest by blank lines. This is the start of providing some structure to the ZK. As the index grew and navigation became more difficult, I created a sub-index, i.e. a “note” whose contents are just links to notes that are strongly interrelated. My first sub-index was titled “Philosophy”. When a sub-index in turn grows too big for easy navigation, it is practical to create another sub-index (e.g. Mathematical Philosophy).
The practicality of this solution, however, is limited—Too many indices and your notes will get “buried”, in the sense that they will lie in too-deep a level for easy navigation. There is a happy medium between, on the one hand, a cluttered index and, on the other, too many levels that impede easy access. Where this happy medium lies is for the ZK’s creator to determine. No hard rules can be given here.
Now, someone may object that in creating sub-indices we are going back to categorization and recreating the main problem of popular notebook applications. My answer to this is that with the use of unique URIs, this is really a non-issue. There is some categorization in the ZK, but it is very loose. Provided we do not go crazy and create levels and levels of sub-indices, our categories can be very broad. Moreover, if a note belongs in different categories, its URI can be simply copied to as many places we feel that it needs to be. Thus the problem of categorization does not arise.
What should go into a Zettel?
Here are some tips on what you can/should include in each note:
- Title: Ideally, it should tell you exactly what is in the note. Some proponents of the ZK method insist that a note should contain a single idea, which would then be easily captured in the title. Personally, I think that is too strict. On the other hand, a note that is too long goes against the spirit of ZK. Your note, even though it is digital, should still be thought of as a physical index card. Therefore, set a limit of words, say, 300 or 500, per note. This way your descriptive title isn’t too long or too broad.1
- The date & time of creation. As mentioned before, this date & time stamp can be used as the file’s unique identifier.
- Abstract: I’ve seen people include an abstract to give themselves an idea of the note’s contents. I think this goes against the Zettelkasten method. You shouldn’t need an abstract. If you do, then your note is too long! Your note is not an academic paper, after all. Break it down.
- Body: The content of the note should be your very own thoughts, chewed on enough so that your note could be published as is (even if you don’t actually intend to publish). This is not easy to achieve! I myself have not always reached this level of sophistication, but it is a worthy goal to keep constantly in mind. You also want to write & re-write your note many times in order to disentangle complex ideas. If your initial thought can be decomposed into several ideas, it would perhaps be better to create several interrelated notes.
- A bibliographical index. More likely than not, your notes will be a result of your reading. It would be extremely helpful to note the source of some of the ideas in the note. The ZK method says little about bibliography management. I myself use markdown’s citation syntax in the body of the text and then a separate bibtex file with all the actual bibliographical information in BibTeX format.
- Links: At the foot of the note you may want to include links for navigation to other notes. In my case, the links in this section lead simply to the main index and the parent sub-indices. Inter-note links are included in the body of the note.
- Tags (?): I personally am not a fan of including tags. The idea behind tagging is that you can filter out search results to include only notes that contain highly-specific keywords, where such keywords are preceded by a special tagging character, such as the pound or hashtag sign (#). The problem with tags, in my view, is that they are unnecessary AND difficult to maintain. First of all, tags need to be very specific to yield good results. This means single-word tags are virtually useless. And, depending on the software you use to implement your ZK, it might be quite difficult to include multiple words for each tag. Second, and relatedly, you will perhaps need a convention (or a key) for the syntax of the tag (e.g. do you include spaces, hyphens, upper-case, etc.?). But now you are taxing your memory. If you forget your tagging conventions, you won’t know how to effectively search with tags, defeating their very purpose. I’ve personally tried tags multiple times, and eventually gave up on them. I never use them. Take my advice, forget about tags and just use a search program (more about that later).
2022 UPDATE: I’m afraid I haven’t been able to stick to this 500-word limit. It is too restrictive, at least for my purposes. Sometimes I want to write a mathematical proof for a theorem (which counts as one idea, I believe) and the number of words easily surpasses 1000. Try as I might, I frequently cannot reduce the number of words without making the note hard to understand for when I need to revisit it. So the rule is, I guess, to just try to be as brief as needed.↩︎