Properties and Tags: Two Layers of Note Information

For a while, I created a lot of Properties in Obsidian. If I recorded the type, status, confidence, and domain of each note, I thought I would be able to filter for anything later. I treated tags in much the same way: if a word looked relevant, I added it.

As the number of notes grew, the opposite happened. I recorded the same fact twice in a folder and a property. Tags and links pointed to the same subjects. A small change in policy meant updating several places together. I had built more classification, yet finding things again became harder.

Now I treat Properties and tags as two separate layers, even though both appear in the same YAML block.

• Properties contain the minimum structure a machine needs to sort and filter.
• tags mark topics I want to find again across multiple contexts.

The starting point is simple: write one fact in one place.

While the spatial-axis post decides where a file belongs, this post looks at the structural and topical information placed on that file. I separated the relationships and reading paths handled by wikilinks and MOCs into the next post.

Properties are not a questionnaire about the note

At first, I thought more properties would describe a note more accurately. I created values such as type, status, confidence, and domain. The problem was that describing something well and actually using that description later were not the same thing.

If I put a file under sources/ while also writing type: source, the same fact lives in two places. They may match at first, but eventually only one side changes. I ended up with notes whose property values were empty or disagreed with their folders. If I never build a list from a value, only its maintenance cost remains.

So I now use just four default Properties.

---
created: 2026-09-01
tags: []
sources:
  - https://example.com/
aliases:
  - Another name
---

created and tags are required. I add sources and aliases only when needed and do not leave empty arrays behind. The one exception is state: archived, which I allow only for a MOC under atlas/ that I no longer revise but retain as a path for exploration or retrospection.

Properties live only in front matter YAML. I do not use inline key:: value fields. A property name keeps the same type across the entire vault, and tags is always an array. Mixed types break filters in Bases first.

What matters here is not the number of fields but their nature. Properties contain values I will actually use for sorting or filtering. I do not move everything into YAML: not the title and author of a source, which read more naturally in the body; not a judgment that my confidence is low; not the next action in a project. The points, line segments, and rays of the time axis are models for thinking, not another type or status to store. Properties are not a survey of every characteristic a note has. They are a small schema for repeated computation.

Tags are topics that cross multiple notes

A tag answers only one question: “Under what topic will I want to find this note again?” My rules are:

• Use between zero and three.
• Use lowercase English kebab-case.
• Do not create hierarchical tags.
• Do not duplicate folder names, note types, or states.
• Do not write #hashtags in the body.
• Create a new tag only when I will retrieve at least three notes for the same reason.

The criterion that catches me most often is whether the note is actually about the tag. If a note covers an incident during a Kubernetes deployment, reliability may be a real topic. Adding dev merely because a development tool appears in the note would make the tag expand without limit.

I do not use tags for proper names either. A tag such as #aws, #node-js, or #kubernetes does not tell me what role that subject plays. I link names as [[AWS]], [[Node.js]], or [[Kubernetes]] instead.

It can be confusing that tags appear among YAML Properties. In storage terms, tags is indeed a property. Its operating role is different, though. While created is a structural fact, tags is a topic filter that expresses multiple membership. Sharing a screen does not mean answering the same question.

Tags also have clear limits. A tag cannot easily preserve the reason or explanation for applying it. As their number grows, both tagging and retrieving by tag become harder. Tags alone cannot describe relationships between tags the way a sentence can.

Tags and wikilinks do not replace one another

Tags are good at collecting results under the same cross-cutting topic. Wikilinks handle people, organizations, products, technologies, and events that I refer to repeatedly, as well as concrete relationships between two ideas. I do not connect every note merely because it shares a topic, and I do not turn a proper name into a tag when there is no topical role for it.

The conclusion is not that wikilinks are better than tags. Tags represent cross-cutting topics; wikilinks represent meaningful relationships. I continue with how I place wikilinks inside sentences and arrange their reading order with MOCs in the post about wikilinks and MOCs.

So where should this information go?

When deciding where to record a piece of information, I work through the following order.

Suppose I am documenting an incident in which a Node stopped in Kubernetes.

With this division, one fact does not appear in two places. A new topic does not require moving the file, and a new subject does not require expanding the tag vocabulary.

When classification looks necessary, I question it first

Before creating a property or tag, I think about the cost of keeping it current rather than the feature it promises.

Can it be computed from existing information? Are its boundaries clear? Will I have a real reason to update it later? If any of these questions is difficult to answer, I do not create the field. If search or a Bases expression can calculate it, I would rather not store it.

The same applies to tags. When a tag grows beyond 30 notes, I do not immediately split it into smaller tags. I first consider making a MOC. If the problem is that a large result set has lost its reading order, it needs guidance more than additional classification. Tags decide what to gather; a MOC guides what to read first.

This is not an argument for using fewer Obsidian features. It is an argument for keeping different features from doing the same job. Properties handle structure; tags handle topics. I continue with how I separate original material, historical records, and thoughts I will keep revising in the post about sources, logs, and wikilinks. When one tool answers one question, the rules become shorter and there are fewer places for them to drift apart.

A note system should ultimately return time, not merely provide the satisfaction of having classified things well. I want to hesitate less when capturing something, understand why it appears when I find it again, and have only one place to update. For now, that is enough for me.