Structure-tags as an alternative to Structure Zettels
"Structure-tags" are a simple idea to order notes.
Presently, notes (zettels) are ordered by filename (or by using "Structure Zettels"). The file-naming convention may be random or allow notes to be listed in a specific order.
Suppose a structure is needed in a randomly arranged zettelkasten, or a different structure is needed in a structured zettelkasten. In that case, this is made possible by creating a "Structure Zettel": a separate note used solely to order or structure other notes.
What if structure notes could be eliminated and notes could be arranged in many different ways depending on multiple contexts? This is where structure-tags come in.
A structure-tag is, in effect, an alternative filename. Notes are ordered (structured) according to that particular context when searching using a structure-tag.
A structure-tag has two parts: the first is the tag's name; the second encodes where a particular note falls within the structure particular to that tag. An example is "#lighting@1"; this may be the first note in a series of notes about lighting. A second note in the series could have the tag "#lighting@2" and so on. If a new note is inserted between the two, the note could have the tag "#lighting@1.1". If a note now needs to be inserted before the first note, it could receive the tag "#lighting@0.1". And, if a note needs to be inserted after "#lighting@1" and before "#lighting@1.1", it could have the tag "#lighting@1.0.1". This is similar to Luhmann's original file-naming convention. The second part of the structure-tag only relates to the order of the notes with that particular tag and doesn't infer any hierarchical relationship, at least not in the way I use structure-tags.
A note may have multiple structure-tags allowing one note to have a defined place in multiple structures or contexts.
In all the current zettelkasten software that I am aware of, searching on a tag lists all notes with that tag according to their original filename. This behaviour means structure-tags do not have a lot of value when using any of these current software solutions. However, I propose that future zettelkasten software incorporate support for structure-tags. So, when searching using a structure-tag (that is, where one or more tags have a structured second part appended to the tag in the form of #tag-name@n, where "n" defines the order), then the software automatically lists those files according to the order defined by the structure-tag, rather than by filename. Any files with the same tag name but without the structured element would be listed after all the files that do include structure-tags. Any files without the structured element of the tag would be listed by their original file name. So, imagine a simple zettelkasten containing the following files, which in turn have the adjacent structure-tags in the body of their text:
As you would expect, the files above are listed according to their filename. Now, if you search the above database using the structure-tag "#lighting" without any further qualification, a subset of these files would be listed, ordered according to the order encoded in the second part of the tag name, thus:
Structure-tags allow notes to be listed randomly according to the date and time the note was entered into the system and allow the same note to be listed in order according to one or more contexts. A note can have one, or multiple contexts, each conferring a different order for that note.
Why is this better than using structure notes? Having files listed in a particular order in the sidebar helps me to further arrange and edit notes quickly and efficiently. I find using structure zettels cumbersome: there's too much clicking and switching between notes. Removing the structure zettel means one step is removed from my thinking process, which means there is less friction in ordering notes when order is important. I find it easier to work this way.
So, if no software currently supports structure-tags, what's their point? Firstly, I hope to create a demand for software to support structure-tags, perhaps starting with "The Archive"? And secondly, structure-tags already have functionality when using the terminal: searching your zettelkasten using grep and sort allows you to list notes according to the order encoded in the structure-tags. I've included a small Z Shell script below that lists files in the desired order for those interested.
As structure-tags are presented here, they can't express a branching hierarchy, whereas structure zettels can. But this deficiency may be addressed by using a different structuring convention than I have used. My primary aim is to order notes according to context and easily insert further notes; branching hierarchies are of less concern.
Of course, structure-tags won't be for everyone. But, if structure-tags are ever adopted and supported by zettelkasten software, their use should be governed by a simple option in the preference pane.
———
Z Shell script
#!/bin/zsh
if [[ "$1" && ("$1" != "-h") ]]
# if there's an argument that isn't "-h", the help flag
then
# clear the screen and print the search term
clear; echo "#$1"
# print files containing the structure-tag in order
# grep: "-d skip" skip directories
# "-o" prints only the search term not the whole line
# sort: "-t" defines the field delimiter, here a colon
# "-k2" sorts by the second field, i.e. everything after the first colon
grep -d skip -o "#"$1"@[^ ]*" * | sort -t: -k2
# print a blank line and any remaining unordered files containing the same tag
echo " "
grep -l -d skip "#"$1"\( \|$\)" *
else
# print the help message
echo "Usage: "$0" structure-tag-name (without # and @)"
fi
Running this script on our example database gives:
#lighting
202201012119.md:#lighting@0.1
202207171258.md:#lighting@1
202104300645.md:#lighting@1.0.1
199909101217.md:#lighting@1.1
200212241718.md:#lighting@2201803021503.md
201910020841.md
Edit @ctietze 2022-06-03: Reformatted code
Howdy, Stranger!
Comments
@GraemeWeston Interesting idea. I already use tags a lot more than others (I suspect, from reading comments on this forum). I often search for combinations of tags, but your suggestion goes a step or two beyond that, introducing more structure into the tagging system. For no supportable reason (at present), I like the idea; will have to think more about how it could be used. Thanks for posting this!
Your idea reminds me of the idea @ZettelDistraction with his combination approach of Time-Based IDs and Folgezettel-IDs.
The part you are missing is the how of the ordering. By "How" I don't mean the technical means (in your case a certain naming convention). I rather mean the nature of the order. You are opting for a hierarchical order which is generated in the filename. That means that you need interact with some kind of file list or manager.
The hierarchy of structure notes is both implicit (by the heterarchical link structure) and explicit on the note. There is more to it than you just see by you eye. The hierarchical aspect of the order is in part accessed in the editor. That means in practice that you have an immediate access and can manipulate the order (here: hierarchical) with the tools of the editor which are more powerful and acessable to the user. In The Archive there are features planned to support the power of the editor to support this manipulation further.
The biggest disadvantage of any order you generate by the filename is that you lose the terrain:
The post by @iamaustinha Using Cartography as a Metaphor for Investigating the Great Folgezettel Debate is way more powerful than it seems to be. The Folgezettel Debate is still on the surface while the real questions are lurking in the shadows. There is a problem of accessing structure and manipulating it but the solution is not purely technical (e.g. using Folgezettel or Structure Notes or both or this or that). The solution can only be found if the difference between terrain and territory is applied to a heterarchical potentially self-similar network of notes:
You see: What I wrote is less abstract than a hierarchical technique of note ordering since my writings address traits of the Zettelkasten that are less abstracted. At the same time, my writing is less understandable.
There is a good illustration for this: If you reduce your diet to calories it is way more simple to understand how to lose weight: Just consume less calories than you burn. The issue is that you don't consume calories and don't even eat food. Your life revolves around emerging, self-stabilising and disappearing habits. Those habits are connected to the meaning of your life that you generate moment by moment.
The meaning of your life and the habits are way more real than calories. The habits are things that you repeatedly do. They are objectively real by virtue of adressing the actual behavior you are exibiting and by being persistent over time instead of changing from moment to moment (imagine a river. He is not compromised of each water molecule and the fish swimming in it but of *that water is flowing and fish is swimming in it). The meaning of your life is subjectively real. (or psychological real if you want).
Still, this calorie myth is persistent because it sterilises something that is living and organic. It moves your thinking away from reality which is organic and messy. The result is beaurocratisation disguised as "scientific".
Coming back to the topic: The spirit of the Zettelkasten Method is more an entry to the complexities of order, heterarchy, self-similarity than a fixed method that you can use to sterilise knowledge work to a "workflow".
The issues in knowledge work are very similar to the issue of health and fitness. You can't solve an organic problem by using a sterile approach to it. Abstraction moves you in a realm in which you have more access to rigor (e.g. math) but it removes you from what you actually want to understand and and become better at.
Ok, I lost myself in the writing process.
My core statement is:
The hierarchy of structure notes is both implicit (by the heterarchical link structure) and explicit on the note. You move the hierarchy from the body of the note to the filename which removes the tools of the editor to manipulate the hierarchy.
Iain McGilchrist (2009): The Master and his Emissary. The Divided Brain and the Making of the Western World, Totton: Yale University Press. p.21. ↩︎
I am a Zettler
@GraemeWeston, your structure tags remind me of a feature that I'd like to implement (see also):
Custom attributes that can have a key and a value. In MultiMarkdown, this could be special tags like
[@:key:value], e.g.[@:progress:draft]or[@:progress:published]. They'd work like regular tags, but a note taking app could allow you to display your list of notes with, say, a "progress" column which would list all available values (e.g. "draft", "published", etc). You could then easily sort your notes list by the values in this column. This would also offer a simple, flexible & expandable solution to implement your structure tags idea.@GraemeWeston wrote:
While I understand your issue, I personally like the flexibility of structure notes. In a structure note, one can easily add subheadings & comments between your note links. And reordering lines in a hierarchy of note links doesn't require to "renumber" any of the other lines.
That said, I agree that rapid re-ordering of notes (or lines/sections in structure notes) is important. I’ve also tried to think about some approaches. My preferred solution would be to instead empower structure notes further, e.g. have the note taking app parse the elements of a structure note and offer to arrange them via drag & drop.
Anyways, personally, I wouldn't give up on structure notes. Instead, let's have our apps make them more powerful.
Doesn't multiple columns in your text editor solve this problem? E.g. there you've the structure note in a left column and your note on the right.
O ye of little faith!
Matthew 8:26.
The system works so far, though fleeting notes
Occupy my time more than finished Zetteln.
You mean to summon me from Niflheim?
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.
Banned from Svartálfaheimr?
I am a Zettler
If only. I went straight to Niflheim. The Zweiter Beauftragter fur Administrative Fragen at the Svartálfaheimr Immigration Authority is delaying my application.
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.