Properties & tagging for queryable notes

Decision. Put structured, single-value metadata (status, date, rating, author) in Properties; use tags for the 1–3 broad topics of a note plus a small set of nested status flags. Query both with Bases by default (core plugin in early access since Obsidian 1.9.0 in May 2025 [1], generally available in 1.9.10 [14]); only add Dataview ⭐ 9.0k [2] when you hit a wall Bases can’t clear — grouping and TASK/CALENDAR/LIST views [11].

Why this chapter exists

A vault without metadata is a folder of orphaned files: you can read each note, but you can’t ask the vault questions (“show me every book I rated 4+ I haven’t finished”, “every meeting note from Q1 tagged #decision”). Properties and tags are how you make the vault queryable; Bases and Dataview are how you query it. Getting the metadata layer right at the intermediate stage saves a painful re-tagging pass later [4].

What each one actually is

Properties are key–value metadata stored in a YAML block at the top of the note, surrounded by ---. The Properties editor renders them above the body without showing raw YAML [5]. Obsidian supports six types: text, number, list, checkbox, date, date & time — pick the type that matches what you’ll filter on (a date stored as text won’t sort right) [5].

Tags are a special property (tags: as a YAML list) or an inline #tag token in the body. Rules: alphabetical letters, digits, _, -, or / for nesting; at least one non-numeric character; no spaces; case-insensitive [6]. Nested tags hierarchically match — tag:#inbox returns #inbox, #inbox/to-read, and #inbox/processing [6].

Note the trap: the singular tag, alias, cssclass keys were deprecated in Obsidian 1.4 and dropped in 1.9 — always use the plural list forms (tags:, aliases:, cssclasses:) [5].

When to use which

The community consensus is that tags and properties overlap heavily — “they’re both just labels you attach to your notes” [7]. The pragmatic split below is what works at intermediate scale, not what’s technically possible.

Rules of thumb:

• If you’d ever want to sort or compute on it → property with the right type [4].
• If it’s a broad topic (“psychology”, “homelab”) with potential children → tag [9].
• If a value is one of a closed set (active/done/archived) → property (Bases filters cleanly; tags work too but pollute the tag pane) [4].
• If you’d want to find the line in the file, not the file itself → inline tag [8].

Naming conventions (do this once, save yourself later)

Practical PKM’s three rules survive intact for both properties and tags [4] [10]:

1. Singular — rating, not ratings; #book, not #books. Plurals create duplicates.
2. Lowercase, no spaces — kebab-case or snake_case, pick one and stick to it. #Journal and #journal are different tags in some contexts and a confusing mess in all of them.
3. Use autocomplete — Obsidian suggests existing property/tag names as you type; accept the suggestion instead of retyping. Misspelling = a new property silently created.

Two more, less obvious:

• Specificity beats generality. Separate newsletter_status and video_status properties beat one shared status when the allowed values differ [4].
• Put defaults in your templates. “Add them to your template files. This basically makes sure that all of the best practices are followed at once” [4]. A book-template that pre-seeds type: book, status: unread, rating: is worth more than any after-the-fact cleanup pass.

A starting taxonomy (3 categories, stop there)

Tags proliferate faster than you can wrangle them; “resist adding more categories until you’ve proven these three aren’t enough” [10]:

• Type — what kind of note is this? type/book, type/meeting, type/idea. Often overlaps with a folder; pick one home.
• Status — current state. status/active, status/archived, status/inbox. Best as a property if the values are a closed set.
• Topic — subject. psychology, homelab, pkm. The most valuable category for serendipity; the most prone to bloat.

If a candidate tag doesn’t fit any of these, ask: “how will I search for this later?” Tags exist for retrieval; if search, links, or folders already find the note, the tag is dead weight [10].

The query layer

You need a query engine for any of this to pay off. The 2026 landscape:

⚠ Bases only reads data stored in YAML properties — inline key::value Dataview metadata is invisible to it [11] [12]. If you’ve been using Dataview’s key:: value syntax in note bodies, migrate that into proper YAML before adopting Bases [11].

Adoption order (the practical path)

1. Add four properties to one template. Pick a single note type (books, meetings, projects). Add status, created, type, plus one type-specific field. Use the Properties UI, not raw YAML.
2. Write one Base. “All my active books.” Filter on type == "book" and status == "reading". Choose Table view. This is the proof that the metadata earns its keep.
3. Tag sparingly, by category. Start with two tags max per note, drawn from your three-category list (type/status/topic). Don’t tag every note — “every note that has a tag needs to mean something” [10].
4. Extend. Add a second template. Add a second Base. Add a third property only when you have a concrete query that needs it.
5. Audit once a month. Open the Tag pane. Rename duplicates with Tag Wrangler ⭐ 899 [13] — right-click → rename propagates the change across the vault.

Pitfalls

• Dates as text. Storing 2026-05-30 in a text property breaks sort and date math in Bases formulas. Use the date type [5].
• Property sprawl from typos. Status: done and status: done are two properties. Always accept autocomplete [4].
• Tag explosion. “Tags seem to proliferate faster than they can be wrangled in” [10]. The cure is restraint at creation, not pruning after.
• Inline key:: value Dataview metadata. Bases can’t see it. Convert to YAML now if you plan to use Bases [11].
• Re-tagging the past. Don’t. Tag forward from the day you settle the taxonomy; old notes get tagged only when you re-open them for unrelated reasons.