What the head of a Zettel should look like

Vinho

I searched a bit in the forum and found bits and bobs about what elements to have at the very beginning of a zettel – this is what I would lean towards at the moment:

# Note title 
[[Zettel-ID]]
Tags: #tag1 #tag2

The Zettel-ID in brackets is useful for quickly looking for backlinks to the note currently opened: notes that link to this note will appear in the search that results from clicking on it.

I like to have the tags at the beginning of a note as well, because it makes it easier to add tags (you don't have to scroll to the end of the note first). Having Tags: at the beginning of the tag-line, makes it possibly to add a tag to a batch of notes relatively easily with Apple's Terminal – you just enter the following command after going to your Zettelkasten-folder (given your notes are stored as Markdown-files): perl -pi -w -e 's/Tags:/Tags: #newtag/g;' *.md
While I'd like to have an easier way to batch-edit tags in the long-run in The Archive, this is the best way I've found so far – and it relies on having a prefix like "Tags: " in the tag-line of the note.

Before I change all my zettels that don't follow this scheme yet and automate the creation of notes with this header, I would appreciate your opinions on it:
Is there anything else that you think is important to have at the very beginning of a zettel? Would you reorder the items I have in any way (e.g. have the Zettel-ID as the very first thing, before the note-title)? Is my "Tags: " prefix really necessary, or is there an easier way to add a tag to several notes at the same time?

Thank you for your thoughts!

mediapathic

This is very similar to what I do, except mine are like

---
title: 201812151448 Writing Technique
tags: #topic #structure
---

# 201812151448 Writing Technique


## notes about the craft itself

- How To Write A Novel Using The Snowflake Method.............[[201812151450]] 
- Story Length .............................................[[201612192342]] 
- The Lester Dent Pulp Paper Master Fiction Plot................[[201812151449 ]] 

etc.

The main difference is that the --- delineate a YAML block which will be handily ignored by anything that exports markdown. So, if I export this as a pdf or whatever, the first line is the first heading. For book notes I can also put an "author" section in there, and in general I can put any metadata I want.

I'm not convinced that my method of writing the title without the [[ ]] is better or worse than what you're doing. I'm still trying figure that out, and I don't generally use backlinks, though perhaps I should.

@Vinho said:

I like to have the tags at the beginning of a note as well, because it makes it easier to add tags (you don't have to scroll to the end of the note first). Having Tags: at the beginning of the tag-line, makes it possibly to add a tag to a batch of notes relatively easily with Apple's Terminal – you just enter the following command after going to your Zettelkasten-folder (given your notes are stored as Markdown-files): perl -pi -w -e 's/Tags:/Tags: #newtag/g;' *.md
While I'd like to have an easier way to batch-edit tags in the long-run in The Archive, this is the best way I've found so far – and it relies on having a prefix like "Tags: " in the tag-line of the note.

This is really cool, and should be completely compatible with the YAML block I've noted again. Also the delineation may give you other opportunities to manipulate metadata more easily in perl. Thanks for that trick!

Sascha

I use this header:

ID Title
#hashtag1 #hashtag2

I don't need any mass changes other than replace one string with another. Therefore, the position of the metadata is not important.

joachiedere

I am right now considering explicitly defining a lot of metadata related to my notes in order to be able to easily retrieve specific notes later on when my archive becomes huge. And I am also considering that I might want to be able to print out single notes if I feel like having them in paper format. For this I am thinking of two different structural setups. One for the structure note and one for the content note.

This is the way I am considering setting up a structure note:

---
type: #structure
category: #literature (alt. #forum or #cinema), #book (alt. #seminar or #documentary)
title: How to write smart notes
id: [[201902051423]]
date: Tuesday, 5 February, 2019 - 14:23
tags: #kw, #zk, #ahrens
...

# Object (alt. Occurence)
Ahrens, S. (2017). How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking. North Charleston, SC: CreateSpace Independent Publishing Platform.

# Summary
Under this heading, I explain shortly why I wanted to read this book, the overall content and my understanding and view of it.

# Notes
X vs. Y................................................... [[201809221456]]
Z......................................................... [[201809221457]]


# Related notes
A......................................................... [[201808221856]]
B......................................................... [[201808221857]]

# References
Ahrens, S. (2017). How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking. North Charleston, SC: CreateSpace Independent Publishing Platform.

And this is the way I am considering setting up a content note:

---
type: #content
title: X vs. Y
id: [[201809221456]]
date: Saturday, 22 September, 2018 - 14:56
tags: #zk
...

Here I describe the X vs. Y idea [@ahrens2017how].

# Related notes
A......................................................... [[201808221856]]
B......................................................... [[201808221857]]

# References
Ahrens, S. (2017). How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking. North Charleston, SC: CreateSpace Independent Publishing Platform.

msteffens

While a YAML (or MultiMarkdown metadata) block is very useful, personally I don't really like that it clogs the top section of the note. At least for Pandoc, I think that the YAML block can occur anywhere (which is good) but I mostly use MultiMarkdown. And these metadata blocks still feel somewhat technical, and may replicate info from the actual note (like the title).

Personally, I like my notes to start with the title. So I put all metadata in a custom metadata block at the bottom of the note (metadata lines start with < and can occur anywhere). This also avoids the need for any metadata labels (like "id:", "date:" or "tags:") since the < prefix clearly marks a line as note metadata for me.

Rendering with MultiMarkdown or Pandoc then requires an extra pre-processing step, but that's a fine trade-off for me (since I don't need this very often), and it can be automated.

Here's an example overview/structure note:

Vinho

Thanks for your interesting replies so far!

@mediapathic: YAML blocks look interesting, that might be something I'm going to start thinking about. I like the idea of hiding metadata when exporting notes – particularly the Zettel-ID and the tags.

@Sascha: Do you ever want to assign a (perhaps new) tag to several notes at once? And if yes, how do you do it by replacing one string with another if you don't have a metadata label like "Tags: " in front of your tags?

@msteffens: Your < blocks would only make the metadata label "Tags: " unnecessary for me, if the tag block was the only such block I had – otherwise I couldn't specify in which metadata block in the notes to add the tag.
An unrelated question: Why have you chosen Zettel-IDs that are different from the YYYYMMDDHHMM ones that Christian and Sascha use?

msteffens

Hi @Vinho, I have logic that can add a tag to multiple notes but I admit it's not straight forward (if some tags exist, match the metadata line containing the tags & add the new tag at the end, otherwise add a new metadata line below the one with the creation date).

My Zettel IDs are a bit special since they are generated by my own home-grown app (which is still in the works), and its use case is somewhat different from solely manually crafted notes. My IDs contain the note's creation date (with millisecond precision) in its base32-encoded form (after Crockford). The encoding keeps the IDs short while still maintaining precision. The latter is helpful e.g. when automatically creating stub notes from annotations in a PDF, and it can also better avoid clashes in a collaborative setup. While these IDs are not as intuitive as pure date-based IDs, the inserted hyphens make them a bit more readable again, and the 4char-blocks (together with the fact that it's digits and letters) actually make them more recognizable for me.

Will

Great discussion around what metadata to include and how to format.
@msteffens post was very eye-opening. Having all the metadata at the end of the note makes the content stand out and helps organize the writing of the note for me. Having the note lead with the title (h1) is something I'd not thought of. Genius. No need for the title to always be paired with the ID. Also, I like the notion of just listing the tags and not placing a "tags:" entry. Little things.
I do want to ask about the stars? What do you use them to signify?

Here what I have now keeping metadata at the bottom of the note.
Maybe this thread should be changed to "What the tail of a Zettel should look like"

msteffens

Hi @Will, I use the stars as some kind of "rating" (from 0 to 5 stars), i.e. to signify current importance of a note for me. Of course, this could also be achieved by other means (like special tags or some key words inserted somewhere). But, while being compact, the stars (and their bright yellowish color) visually stand out and this helps me to recognize them easily.

Having the stars as an additional (and separate) means of note organization helps me to keep the tags content-focused. Also, having an indicator of current importance helps to quickly accumulate all starred notes (via a search), or sort by them (via a "Rating" column in my app).

Sascha

@Vinho said
@Sascha: Do you ever want to assign a (perhaps new) tag to several notes at once? And if yes, how do you do it by replacing one string with another if you don't have a metadata label like "Tags: " in front of your tags?

It is very rare that I edit more than one note at once. I never assign tags to multiple notes. But I replace strings with another. For that I just use search and replace with textmate which allows to use this function across project folders.

When I search for a string and want it to replaced with another, I use search and replace by an editor.

Will

Thanks, @msteffens. ★★★★★

The use of stars for the relevant importance of a note is brilliant. The way I look at importance is how many times have I referred to a particular note. Either by linking to it or by using it in my writing. It gains importance as I use more and more. Easy to add stars as a note gets more and more use.

Linking relevance/importance is seen by the number of 'back-links' but the number of uses of a particular note has been nebulous till now. Now I can track this with star tagging.

Now I just need to figure out how to automate the back-lining and edit the themes in The Archive so the stars can have a unique color.

Vinho

After taking into consideration all your inputs, I'm using this header for now:

[[Zettel-ID]] #tag1 #tag2

# Note title

Note body 

• I decided against a YAML-block, because the two --- lines take space away and I won't export notes often.
• I decided to put the metadata right at the beginning to not have "clutter" between the note title and the note body. Also, the workflow to create this header is a bit smoother – I can just copy the file name (that I usually entered before in the style Zettel-ID note title and don't need to change the order between the Zettel-ID and the note title anymore.
• To have the Zettel-ID and the tags in one line saves space and makes it still possible to batch-add tags to notes using the Terminal-command mentioned above. I just replace the string ]] # (which probably won't appear anywhere else except from in the first line of notes) with ]] #newtag #.

Let's see for how long I'm satisfied with this

Will

This is my format for new content notes. This puts all metadata at the end of the note and keeps them out of the way when I'm creating a note. I originally found that I was distracted and would right away start a note then try adding tags and links even before I had all the content flushed out. Wrong priorities. A personal problem that is helped by placing metadata after note.

This has been a great discussion and I've gained greatly by all your input.

argonsnorts

Plus one for keeping metadata at the top of the note, because I don't really think of it as being "in the way" there. Also, I have found it useful to have a section of fairly general "back" links and "forward" links at the top, as an easy-to-locate supplement to whatever links appear in the note itself.

I should say, the designations of "back" and "forward" are really somewhat arbitrary, as they do not necessarily signify chronology or hierarchy. I create them sort of ad hoc, as I think they might be useful, and I feel no compunction about changing them or deleting them. (If more than 3 or 4 stack up, I feel like I'm doing something wrong and I reassess the strength and relevance of the links.) A "back" link typically points either to a more general note on the subject addressed in the present note, like a structure note, or to the specific note from which the present note originated. A "forward" link could point to literally any note that I think might be relevant but which does not appear in the text of the present note itself. These links help me navigate through "subjects" in my Zettelkasten, moving from note to note, as an alternative to relying on structure notes, or having to survey a list of notes with the same tag or search term. It feels a bit more like perusing a stack of note cards.

# [[201902101214]] Title
===
tags: #tag1 #tag2
===
<-- [[201805111419]] Ü1 Structure note
--> [[201804071702]] Some other note 
===

Body of note

ctietze

Side note: Back in 2009, I started to add Ids of notes that were predecessors and successors into the header. I completely removed this. Forward links are part of the text. If Note 123 contains a mistake, I either correct it or place a big This is wrong! See [[456]] for the new truth!! at the top. I found myself using too much time for organizing a note, finding back- and forward link targets, compared to actually writing more notes. Relying on every link to be part of the text a few years later didn't surface any downsides so far. On the contrary, I don't have to worry about filling out the form properly and can simple link in a natural way, which is the way I consume notes: by reading and absorbing the context, then following links when I think they are relevant.

Will

Yes @ctietze, once again you've clarified this process for me. I also have found myself spending "... too much time for organizing a note, finding back- and forward link targets, compared to actually writing more notes." Having the metadata short, out of the way, and being flexible helps a lot. Your suggestion about inline links is a trick/tool to add to the toolbox.

@argonsnorts
I'm a bit confused about "back" and "forward" links. When I think of backlinks I think that if I link to note B from note A, then from note B I'd want to link "back" to the note A. Sort of a bookkeeping/maintenance operation. Closing a loop. Creating 2-way links.

mediapathic

I don't see the point of making a 2-way link, when a "link" is always just going to be a search on that UID string, so should bring up the referencer as well (unless one explicitly jumps to the "result in title" as opposed to "result in body". Am I missing something there?

Will

@mediapathic You are correct. I was over thinking it or not thinking at all. This is an advantage of using a UID. Looking at this closer and your tip, make me wonder who it was that was making such a big deal over "backlinks".

How can you "unless one explicitly jumps to the "result in title" as opposed to "result in body""? I'd love to be able to search in the body of a note and get the UID and title as a return. Think this might be possible?

Sascha

@mediapathic said:
I don't see the point of making a 2-way link, when a "link" is always just going to be a search on that UID string, so should bring up the referencer as well (unless one explicitly jumps to the "result in title" as opposed to "result in body". Am I missing something there?

That is exactly my point in not caring about backlinks. They are built into the links as search.

argonsnorts

@mediapathic said:
I don't see the point of making a 2-way link, when a "link" is always just going to be a search on that UID string, so should bring up the referencer as well (unless one explicitly jumps to the "result in title" as opposed to "result in body". Am I missing something there?

This is only the case in interfaces with an Omnibar, like The Archive and nvALT. In SublimelessZK and 1Writer for iOS, on the other hand, it is quite useful to have some key "links" in the header, particularly the note from which a new note is "branched."

mediapathic

@Will said:

How can you "unless one explicitly jumps to the "result in title" as opposed to "result in body""? I'd love to be able to search in the body of a note and get the UID and title as a return. Think this might be possible?

I was thinking here of implementations such as what Magnus did here in emacs wherein there is a function to just open the note (as opposed to a list of results) if the result of a search is unique. So, not really what I think you are wanting here.

mediapathic

@argonsnorts said:

This is only the case in interfaces with an Omnibar, like The Archive and nvALT. In SublimelessZK and 1Writer for iOS, on the other hand, it is quite useful to have some key "links" in the header, particularly the note from which a new note is "branched."

True! I suppose this comes down to which tools one uses most often.

gescho

@mediapathic said:
I don't see the point of making a 2-way link, when a "link" is always just going to be a search on that UID string, so should bring up the referencer as well (unless one explicitly jumps to the "result in title" as opposed to "result in body". Am I missing something there?

Another consideration is that full-text searching for a note ID will surface all backlinks to that note. So in that way back links are a handy way to see the 'surroundings' of a note with a search query. Especially since most text editors do not include functionality that graphically represents links.

When I incorporate book notes into my ZK, I also paste back-links to the source material first. I use Evernote - a quick search for the ID string of the source material and a right-click - copy all internal link, and the source has all the ZK ids. Again, that means that the source always surfaces in searches. That also means that the source (a EverNote containing a website clipping, a e-book or a empty reference to a physical book, etc.) is a sort of structure/hub note on it's own. Connect sources the same way and you have an alternative way to traverse your Zettelkasten.

garrickbailey

Most of you have the same format for related notes at the tail of your notes—i.e. Title....................[[zettel ID]].

Is this something you type in manually, copy/paste, or have a fancy automation for (e.g. Keyboard Maestro macro)?

Will

@garrickbailey I use a "fancy automation" via Keyboard Maestro. Macro and explanation at https://forum.zettelkasten.de/discussion/comment/2297/#Comment_2297