They don’t. Any app with search will find any part of the string in simple search.
You’re seeing them as a form of metadata, which is only one way of viewing them. Another is seeing them as coloured pills containing an address. An address constructed like a file path. There’s a value to seeing them directly in the note in that form, which doesn’t involve any form of search at all and which isn’t duplicated by using multiple single tags.
I hope I understood the principle of creating a tag. My question relates to “lead” and “aliases” how do I use them? What will I need them for in our method?
Thank you for asking, @gajer . Here is how I use:
And my Dataview example:
TABLE WITHOUT ID
file.link as Terms,
lead AS "Definitions",
length(file.inlinks) as "In"
FROM #type/term OR #type/tool
WHERE lead != empty
SORT file.name ASC
Is it useful for your workflow?
Tank You! I’m starting to create zettelkasten and I’m already amazed at how it affects my work. A recent question about metadata. How to hide red marked metadata in View:reading page?
It‘s easy to hide lines by using # at the beginning of each hidden line.
# is used in YAML for marking comments.
If they did that they wouldn’t be able to use their metadata (except by reading it with their eyeballs).
I look forward to reading everything here for ideas. In the meantime here is how I use tags, which works very effectively for me:
IMHO sometimes people get too wrapped up in processes and at the end of the day all that matters with tags is that they help you find what you want easily, which should be pretty easy if you are using a tagging system that reflects the way you think. If tags are for teams it becomes more complicated.
As a practice I attempt to give everything at least one broad subject tag and one specific subject tag. So an article on depression might get #psychology for a broad tag and #depression for a specific tag. And then adding in other tags such as person (#Robin Williams) makes it easier and easier to find what you are looking for quickly.
HTH someone.
This is a question I often make to myself too. First level tags are easier to ‘add up’ to a note, but they also provide less organizational value. I often use both, but I’m not happy about it
Hello Edmund. I’m just starting with Zettlekasten and I’m reading a lot about how to organize my vault to get it clear from the beginning. I liked your system, I think it might fit my way of working. I have some initial doubts:
Thank you very much for all the information you have shared.
Thank you for the question about “tags vs properties”. 
With a Zettelkasten in Obsidian you will always have many options to reach your goal. My first goal for tagging is to use them for searching. Tags are best thought of as specially designated search terms. I use them for Dataview queries and for filtering Graph Views as well. And my tags are based on a solid tag architecture.
Last but not least, I started my first year of Zettelkasten using notes with plain markdown without any use of YAML, frontmatter or properties. Maybe today you can find a better solution to reach your goals.
I’ve been using Logseq for over a year now, so I’m used to using properties and queries.
I just want to learn how to use Obsidian queries and realize from the beginning how to apply a Zettlekasten method very similar to the one you shared. Thank you Edmond, I will continue reading what you have written.
I’d like to add my voice to this discussion, since it’s still alive. So lets try a first shot.
Brief digression, very recently on Youtube I watched a video (1) which showed that few of the “Design patterns” (2) were still being used in practice in code developed using modern languages such as Python. The reason for this was, to put it briefly, that these languages had natively integrated certain “patterns” and offered solutions that made it possible to do without others.
On the question of “tags vs links” in the context of Obsidian, the situation is much the same:
Obsidian allows us to achieve a goal in many different ways (3), but it may be useful to highlight the differences between the various tools: Folder, Tags, Properties, Links…
To try and put things in order, it’s interesting to look at what distinguishes these different tools.
Leaving aside for the moment the ergo/cognitive aspects, I’m going to focus on four qualities(4)although other qualities can easily be envisioned(5):
Intrinsic: This quality refers to characteristics that are inherent to the notes themselves. For example, a tag written directly in a note is intrinsic because it’s part of the note’s content.
Unique: This means a note can have only one instance of this characteristic. For instance, a note can belong to just one folder at a time in its primary location (4).
Hierarchical: The tool can directly support a hierarchy
Collection: The tool can be use to group or collect multiple items together,
| Intrinsic | Unique | Supports Hierarchy | Can Collect Multiple Items | |
|---|---|---|---|---|
| Folders | no | yes | yes | no |
| Properties | yes | no | no | yes |
| Tags | yes | no | yes | no |
| Links | yes | no | no | ? |
| - outbound (MOC) | yes | no | no | no |
| - inbound (TOC) | yes | no | no | yes |
Moving beyond the inherent qualities of these tools, it’s also crucial to consider their practical aspects in terms of modification. How easily can we attribute, remove, rename, split, or merge elements within each tool? This aspect is particularly important when managing a dynamic knowledge base where information constantly evolves. To provide clarity on this, the following table categorizes Folders, Properties, Tags, and Links (including outbound (MOC) and inbound (TOC) links) based on their ease of modification across five key actions: Attributing, Removing, Renaming, Splitting, and Merging. Understanding these aspects helps in selecting the most appropriate tool for specific tasks within Obsidian.
| Attribution | Removing | Renaming | Splitting | Merging | |
|---|---|---|---|---|---|
| Folders | easy | easy | easy | easy | easy |
| Properties | easy | easy | not so easy | need some work | need some work |
| Tags | easy | easy | not so easy | not so easy | not so easy |
| Links | |||||
| - outbound (MOC) | not so easy | not so easy | easy | not so easy | not so easy |
| - inbound (TOC) | easy | easy | easy | not so easy | not so easy |
Best uses for each tool —Tags, Links, Folders, and Properties— in Obsidian, is a matter of taste, parameter are numerous, we have only scratched the surface.
Did I just stated the obvious?
Edited 20231117
Excellent post! Thanks so much!
I’m confused about “can collect multiple items.” A folder, for example, can contain multiple files, tags can be attached to multiple files, files can contain multiple outbound and inbound links. Clearly I am misinterpreting your meaning.
Maybe, I I should have written “can be a collection”. For instance a property, conveniently named “Authors”, and is IMHO best suited to attribute a list of authors to a note as often a piece of work has many authors.
Thanks, but I’m still not seeing it, I’m afraid.
To use your example: You can designate each author with a tag — #ShakespeareWilliam #DickensCharles #ChristieAgatha — and therefore tags can be a collection.
Clearly I am misunderstanding what you intend to say.
You can have a tag for each author.
But if you want to iterate on these authors, it is much more easy if they are in a list as an “Authors” property provide.
Now, If instead of using an “Authors” property, you use structured tags (#author/name1, #author/name2), you get back the idea of a collection of authors. But, 1) it will be less easy to iterate on the authors, 2) you may be confused if the same person appears with other roles in this note or other notes. For instance, in the movies industry, a person can be: an actor, a playwriter, a cinematographer or a producer.
To generalize, the tag hierarchy problem, it is IMHO awkward to represent a local binding: the fact that name1 is an author of this note, by using a global tool as the tags namespace.
On the other hand, if you simply tag a person, you can much more easily search for the notes in witch it appears. Note: links to the person note could assume the same functionality .
In fact, it seams to me that the best solution would be that property list items could be native tags or links without caveats . May be we only need to wait a bit.
First of all: Thank you for your brilliant analysis!
Looking at your “Ease of use table” my first idea was to only choose the two lines “Folders” and “Links”. All five elements (Attribution etc.) are characterized with “easy”.
Isn’t it the final solution for a Zettelkasten? - I’m not sure.
Ease of use is not the only need.
When folders can support the semantic, as for periodic notes they are great.
An error in the table, the Links row should not be filled, and the Links are outbound or inbound.
My own personal take… I find tags to be useful for topics, links (files) are useful for specific assertions about a topic or for establishing a relationship between other assertions and sources of ideas, and folders are for the type of input or output.
Tags are signals: we write something down from a source, and then give it a tag which signals to our future selves that there is something of value here. Personally, I find this to be preferable than topical links because I have greater visibility of tags than of links and therefore they are easier (for me) to manage, especially using Tag Wrangler or VS Code find and replace. It also helps me to have far fewer notes to keep track of.
It depends on your personal preferences, habits and the type of notes you works on, but here is how I use tags.
I use tags for specific elements in my notes, such as equations, todos, etc and NOT for notes themselves.
For notes I use properties and with dataview I can filter them however I want.
