Use Tags. But how?

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.

1 Like

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.

2 Likes

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?

1 Like

Thank you for asking, @gajer . Here is how I use:

  1. Aliases - From Obsidian help you will find: Aliases - Obsidian Help
  2. Lead - I always put the text from my lead paragraph (the main idea of my note) to the front matter. - Why? When using Dataview it‘s very easy to build up a list of note titles and leads. It‘s like having a dictionary with terms and definitions.

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?

1 Like

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:

  • Attribute Tags (#blog, #interesting, et al)
  • Subject Tags - Broad (#History, #Computing et al - it’s important to use tags here that are broad for YOU. For example although photography would typically not be a “broad” tag, if you are deeply into photography it could be). I have less than 20 broad categories.
  • Subject Tags - Specific (#WWII, #Wordpress et al). While I typically use very targeted tags here, when it suits me I use “descriptive” tags. For instance instead of #Wordpress and # Plugins I would just use “#wordpress plugins”. I have a few hundred specific tags.
  • Company Tags (#Microsoft, #Intel)
  • People Tags (#Michael Jordan, #Larry Bird)
  • Location Tags (#California, #Oregon)

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.

1 Like

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:

  • Why do you use tags for everything, why not put as property “Type: Book” instead of as tag “type/book”? If I bring a list of books and I want to bring the themes “theme/productivity” or “theme/writing”, I would also get “type/book” between the tags.

Thank you very much for all the information you have shared.

1 Like

Thank you for the question about “tags vs properties”. :slight_smile:

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.

1 Like

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.

1 Like

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.

Characteristic qualities

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,

Characteristics table

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

Ease of Use qualities

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.

Ease of use table

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

Some hints for the use of each tool

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.

  • Folders
    Match the files organisation
    Best Use: Folders, being unique and hierarchical, are excellent for primary organization based on broad categories or distinct projects. They offer a clear, top-down view of your notes.
    Overlap with Tags: Folders can be complemented with tags for a more nuanced organization. For instance, a folder might contain all notes for a specific project, while tags within that folder might denote different phases, topics, or priorities within the project.
  • Tags
    Implement easily a hierarchy
    Best Use: Tags are ideal for cross-referencing and thematic grouping. They’re intrinsic, non-unique, and can be hierarchical, making them perfect for categorizing notes that span multiple topics or projects. And they are easy to attribute, may be even a bit too much.
    Combining with other tools: Tags work well with folders for a two-tier organization system. While folders can categorize notes by primary subject or project, tags can further classify notes within these categories by themes, types, or statuses.
  • Properties
    Easy to process
    Best Use: Properties are useful for detailed, attribute-based organization. They can group notes by specific characteristics, such as date, author, or status. Properties are intrinsic but not unique, allowing for flexible categorization. But as they are not so easy to maintain. so they may be used for stable attributes.
    Synergy with Folders and Tags: Properties can refine the organization within folders or tag groups. For example, within a project folder, properties can differentiate notes based on their completion status or relevance.
  • Links
    Not bounded
    Best Use: Links (both inbound and outbound) are fundamental for creating a network of interconnected notes. But this is not the point in this note. Links are intrinsic and support easy modification, which makes them suitable for evolving knowledge bases where connections between ideas develop over time.
    Interactions with Tags and Folders: Links can be used to bridge notes across different folders or tag groups, creating a web of information that transcends simple hierarchical structures.

And now

Did I just stated the obvious?

  1. Classic Design Patterns: Where Are They Now - Brandon Rhodes - code::dive 2022 https://youtu.be/pGq7Cr2ekVM
  2. Gang of Four Design Pattern (Gang of Four Design Patterns - Spring Framework Guru)
  3. And the user is the one who can decide what’s most convenient for him or her, which I’m sure we all agree is the case.
  4. At first glance. It appears that if a characteristic is not Intrinsic (part of the note itself), it must be Unique (only one instance per note). However, this isn’t necessarily true. The tools could use external tables (“Not Intrinsic” and “Not Unique”) or use file system symbolic links to stay with folders.
  5. I am thinking the inheritance, and more precisely to multiple-inheritance

Edited 20231117

10 Likes

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.

2 Likes

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.

1 Like

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.