@HITshrink wrote:
I used tags to identify topics as well as dates… less so for status.
For me it was an amazing benefit NOT using tags for dates. I decided to use variables like „date“, „created“ or „year“ instead within my YAML frontmatter. So now it is easy to generate filtered lists and tables with Dataview plugin.
Yep, I have been working towards using YAML/DV date fields, but haven’t yet found a schema that quite fits or that I am consistent with. I think it might happen in
targetdate:: 2023
if I have time to futz with it. But I am in this betwixt stage now #2023y [[2023y]].
I understand tags like #role/author
I kind of understand #index
But I don’t get #theme
Or is the actual topic appended as for the roles?
#theme/gardening
That totally depends on the topic!
Notes about different customers are better stored in folders - they could even be in different vaults. You normally don’t want them to be mixed.
Same for anything that just needs the same note names!
A/introduction.md
A/summary.md
B /introduction.md
B/summary.md
So your “tags over folders” may be applicable if otherwise no other reasons demand for folders 
Just saying…
Cannot edit the above anymore (I HATE that):
And, where there is no need to access your content with other Apps then Obsidian
If you need audio files or PDFs or images or even markdown files that belong together, you will that they are in folders and not spread somehwhere or - worse - together with thousands of not-related files.
So, again - it depends!
Strongly.
@tja, Yes it is like: #theme/gardening
Here is the the top of my #theme/… list:
But, as you see it from the numbers, my notes are not completely tagged. I use the theme-tagging only for clustering my “important” notes.
This is so much useful !! Thank you ! 
Today I decided to clean up my tag structures. The tags I choose should reflect the way I think about and organize my notes.
“Tags provide architecture, not content.” — Austin Govella
The most important thing is to be consistent in my use of tags and to choose tags that make sense to me. But after a view month of use they look a bit messy and there is a need for refactoring.
The Obsidian Canvas is published at Obsidian-Zettelkasten-Starter-Kit / Starter-Kit / Canvases /
I just recently started re-structuring my notes to use tags, because I realized that my complex folder structure was–well–unnecessarily complex. I have a few questions about tags:
How do you choose what is a folder and what is a tag?
For example, how do you decide whether to tag a note #project/game/fantasy or put the note in the Projects/Games/Fantasy folder? Or…whether to put the note in the Projects folder and give it a #game/fantasy tag? Is there an optimal method? Does it matter?
What is the better method, using tags like they’re folders, or using tags like they’re metadata fields?
I’ve mostly seen tags used like folders, like in the example above, but I also noticed in some examples people use them like fields. Like, #genre/fantasy. Is one method more beneficial than the other? Can the two be combined? Should the two be combined?
When should you use nested tags and when should you stick to first-level tags?
Is there significance to tagging a note #character/antagonist #recurring-character instead of tagging it #character/antagonist #character/recurring-character or #character/antagonist/recurring-character? This one in particular has me…confused. Does the difference matter?
Maybe I’m thinking about it too much, but I am divided as to how I should continue to tag things.
I’m not an expert on this, but like many I also have struggled with this. A lot depends on your preference. What works for somebody else doesn’t need to work for you.
It would be good to define the one or two major problems you have with your current setup. Then you are able to determine if a new setup solves it.
Probably it is the best to keep it simple. Maybe just use one method and not tags AND folders. Creating nested tags with too many levels will lose it’s flexibility just like using folders.
The main thing is that a note can only be in 1 folder but can have many tags.
Tags as folders only make sense if you’re not using actual folders.
I don’t use nested tags myself because I prefer the simplicity of single-level tags. The beauty of a hashtag is that you don’t need an app that supports tags — only one that supports search. Hierarchical tags require fancier search. But it’s a matter of taste.
That’s a good point.
That makes a lot of sense. I guess the goal of using tags isn’t to make a structure, it is to make things easier. My problem is that I keep overthinking things and making it harder than it needs to be.
Thanks for sharing your ideas, I think I understand the purpose of tags better now.
It’s not necessary to regard hierarchical tags as something complex requiring sophisticated search. There’s information embedded in the hierarchical name. Only apparent of course with tags - unseen in YAML.
They require more complicated search if you want to use them in apps that don’t explicitly support tags — but as I said, that doesn’t matter to everyone.
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).
