# Obsidian Properties Properties (also called metadata or frontmatter) are structured fields attached to a note in [[Obsidian]]. They live at the very top of the file, between two `---` lines, in a data format called [[Yet Another Markup Language (YAML)]]. Here's an example: ```yaml --- title: Atomic Habits authors: - James Clear status: Reading rating: ★★★★☆ pages: 320 --- ``` The note's content is what the note says. Properties are a bag of information about that note: its type, its status, its dates, its relationships to other notes, pointers to other notes, links to Web pages, etc. The block at the top of the file is what's called **YAML front matter**, and it is NOT an Obsidian invention. The convention was popularized by Jekyll, the static site generator behind [[GitHub Pages]], back in 2008, and it has since become a de-facto standard across the [[Markdown]] world. Hugo, Astro, Eleventy, and Quartz build entire websites from it. Logseq and Zettlr read it. Pandoc understands it. GitHub even renders it as a neat table. Obsidian adopted an existing standard rather than inventing its own, which makes the metadata portable across an entire ecosystem of tools. The format has three rules worth knowing: each property is a `name: value` pair with a colon and a space, each name must be unique within the note, and the order doesn't matter. Fun fact: the block can even be written as [[JavaScript Object Notation (JSON)]], and Obsidian will quietly convert it to YAML when saving. In practice, you rarely need to touch the YAML directly. Obsidian ships a visual property editor that sits at the top of every note through its [[Properties view core plugin for Obsidian|Properties view core plugin]]. Click, type, done. ![[Adding a property.png]] Caption: Adding a property to a note using Obsidian's visual property editor Properties live INSIDE the notes, as plain text in Markdown files, respecting the [[File over app principle]]. No lock-in, no proprietary format. If Obsidian disappeared tomorrow, every property ever filled in would still be there, readable by any text editor and any tool that understands YAML front matter. ## The six property types Obsidian supports six property types: 1. **Text**: the default. Names, descriptions, links, etc. 2. **List**: multiple values. Tags, aliases, and cssclasses are lists under the hood. 3. **Number**: integers and decimals. Page counts, scores, priorities. 4. **Checkbox**: true or false. Published? Reviewed? Done? 5. **Date**: a calendar date with a date picker. Bonus: with the Daily notes plugin enabled, date values become clickable links to the corresponding daily note. 6. **Date & time**: same, plus the time. ![[obsidian-properties-six-property-types.jpg]] Caption: The six property types: Text, List, Number, Checkbox, Date, and Date & time There's technically a seventh: **Tags**, a special list type reserved for the `tags` property alone. It can't be assigned to anything else. In addition, the `aliases` and `cssclasses` property names are also reserved. Aliases are alternative names for notes, usable through the `|` in Obsidian links (e.g., `[[My note|This is an alias of that note]]`), which is super useful to include links in notes without breaking the flow of sentences. To change a property's type, click the type icon to the left of the property name and pick the new type. Types can also be managed from the All properties pane. ![[property type.png]] Caption: Changing the type of a property in Obsidian The type determines what you can DO with the value later. A date stored as text can't be sorted chronologically. A number stored as text can't be summed or averaged in a Base. A checkbox stored as the text "yes" can't be filtered as a boolean. Pick the right type the first time: changing it later, once hundreds of notes carry the old format, is painful. Property names are case sensitive under the hood: `Status` and `status` are two DIFFERENT properties, even though the editor displays them alike. Pick a casing convention (e.g., `snake_case`, all lowercase) and remain consistent. ## Property types are vault-wide When a type is assigned to a property, that assignment applies to the WHOLE vault. It isn't stored in the note; it's stored in a "hidden" file called `types.json` inside the `.obsidian` folder, mapping each property name to exactly one type: ```json { "types": { "pages": "number", "rating": "text", "date_published": "date" } } ``` One name, one type, everywhere. Only explicit type assignments are stored there; properties absent from `types.json` get their type inferred from the YAML value. The assigned type changes the widget Obsidian's property view shows; the actual YAML value can still disagree, in which case Obsidian shows a "type mismatch" warning. Importantly, Obsidian has NO notion of note types. To Obsidian, there are only notes and a single global list of property names. If `pages` means "page count" (a number) on book notes and one day `pages` is used on a website note to list sub-pages (a list of links), the two collide and one becomes invalid. There's an [open feature request about a type system in the official forum](https://forum.obsidian.md/t/super-fr-enhance-obsidian-with-a-type-system-for-notes-and-database-like-views-metadata-object-oriented-model/46444). Consequences: - **Property names are a global namespace.** Name properties as if every note in the vault could carry them one day, because as far as Obsidian is concerned, it can. - **Real note types have to be built on top**, with conventions and/or templates/tooling. This is why the [[Obsidian Starter Kit plugin for Obsidian|Obsidian Starter Kit plugin]] exists: actual note types, each with its own schema (which properties a book note must have, which values `status` may take on a task, what's required and optional), with recognition, validation, automated filing, and a type registry exported to files that scripts and AI agents can read. ## Day-to-day features - **Add a property from anywhere**: `Ctrl+;` (or `Cmd+;` on macOS) in any note. See [[Obsidian Keyboard Shortcuts]]. - **Autocompletion**: Obsidian suggests existing property names and values while typing. Accepting a suggestion instead of inventing a variant makes the vault more consistent. ![[Tags property auto completion.png]] Caption: Obsidian autocompleting property values based on what already exists in the vault - **Links inside properties**: properties can hold `[[wikilinks]]`. This is how tasks connect to projects (via `related_projects`), books to authors (via `authors`), etc. Those links show up in the [[Graph view core plugin for Obsidian|Local and Global graph view]] and in backlinks, just like links in the body. External URLs work too. One gotcha: in raw YAML, wikilinks must be wrapped in quotes (`"[[Some Note]]"`). The visual editor quotes them automatically, but templates and scripts must pay attention to that. - **The File properties pane**: shows all properties of the current note in the sidebar. - **The All properties pane**: lists every property used across the entire vault. A useful audit tool. ![[file properties.png]] Caption: The File properties pane in Obsidian's sidebar ![[the all properties view.png]] Caption: The All properties pane, listing every property across the vault ![[properties views.png]] Caption: Opening the File properties and All properties panes from the command palette - **Search by property**: Obsidian's search supports `[property]` to find notes having a property, and `[property:value]` to match values. For example, `[status:60 - In Progress]` finds everything currently in progress. - **Properties work on mobile too**: same editor, same types, same data. ## Tips, tricks, and sharp edges ### Seeing the raw YAML (Source mode) Two ways: 1. **Per note**: command palette → "Toggle Live Preview/Source mode". 2. **Globally**: Settings → Editor → "Properties in document": **Visible** (visual editor, default), **Hidden** (only in the sidebar pane), or **Source** (raw YAML everywhere). This is useful whenever a property turns orange: Obsidian highlights values that don't match the property's assigned type or contain malformed YAML, and the visual editor often refuses to edit those broken fields. Source mode lets you fix the text directly. Silent failures to know about: - The opening `---` must be the very FIRST line of the file. So much as a blank line above it, and Obsidian treats the whole block as plain text. - Adding the same property name twice isn't allowed; the duplicate entry must be removed for the properties to work again. ### Reserved property names - `tags`: the note's tags (the special Tags type). - `aliases`: alternative names for the note. Underused and powerful: aliases show up in the quick switcher and in link autocompletion. - `cssclasses`: CSS classes applied to that note only. Per-note styling, straight from a property. - For [[Obsidian Publish]] users: `publish`, `permalink`, `description`, `image`, and `cover` control publishing and social previews. Heads-up for old vaults: the singular forms (`tag`, `alias`, `cssclass`) were deprecated in 1.4 and dropped entirely in 1.9. ### Small moves, big time savings - **Reorder properties by dragging** the icon next to their name (or let the Linter enforce one order everywhere). - **Rename a property across the vault**: right-click it in the All properties pane and rename once. Obsidian updates every note that carries it. THE tool for merging synonym properties. - **Navigate with the keyboard**: `Tab`/`Shift+Tab` move between fields, arrow keys move through the list, `Ctrl/Cmd+Backspace` deletes a property, `Escape` returns focus to the editor. - **Insert multiple templates into one note** and Obsidian merges their properties: list properties (like `tags`) combine their values; single-value properties keep the LAST value inserted. ### What properties won't do - **No Markdown rendering** inside property values. Properties are data, and that's intentional. - **No computed values.** A Number property stores literal numbers; `3 + 4` won't evaluate. Calculations belong in Bases formulas. - **No nested properties.** YAML supports nesting; Obsidian's editor doesn't. Keep the schema flat. - **No native bulk editing.** For mass changes, use the Linter, a script, or an AI agent. Tip: for computed properties or value projections/interpolations based on the properties of other notes, see the [[Expander plugin for Obsidian]]. ## Avoid metadata sprawl The trap: you discover properties, get excited, and start adding fields to everything (`mood`, `weather`, `energy`, `source`, `origin`, `from`, ...). Six months later the All properties pane shows 200 property names, half of them used exactly once, four of them meaning the same thing, two of them differing only by capitalization. Some people abandon their metadata entirely at that point. [[Nick Milo]] warns about becoming "a janitor of metadata", and it's the right framing. Properties must be treated as a schema. > **A property is a promise.** It says: "this field means the same thing on every note (of the same type!) that carries it." Break that promise often enough, and no query, no dashboard, and no AI will ever be able to rely on your vault. Typical issues: 1. **Synonyms**: `finished`, `date_completed`, and `done_on` all meaning "when I finished this". Pick one. Merge the rest (right-click → rename in the All properties pane). 2. **Case inconsistency**: `Status` vs `status`. These are different properties. One convention, forever. 3. **Lack of a clear naming convention**: `date_added` vs `dateModified`. 4. **Orphans**: properties added "just in case" that no query ever reads. Dead weight. 5. **Lack of clarity about data types**: `estimate` vs `estimate_minutes`. Naming matters; ambiguity leads to inconsistent values. The fix is not just discipline, because discipline doesn't scale. What's needed is a schema, careful design, plus automation (templates, AI skills, ...). ## Design properties like a schema Whether you realize it or not, an Obsidian vault IS a database. Every note is a record. Properties are its fields. And databases live or die by their schema. Rules that hold up at 20,000+ notes: ### 1. One property, one meaning `rating` means the personal star rating. Everywhere. On books, on articles, on courses. It never means "difficulty" or "priority" on some other note type. When a field means something different, it gets a different name. One nuance: shared names work when something scopes them. `status` can carry different value sets on tasks, articles, and books when each note TYPE defines its own ladder. Without note types, split the name instead (`newsletter_status`, `video_status`) rather than overloading one property with mixed vocabularies. Overloaded properties also poison autocomplete. ### 2. Add a property only when a question needs it Before adding a field, ask: **what query, view, or automation will read this?** If none can be named, don't add the property. This is the single most effective rule against sprawl. Metadata is an interface: something has to read it, or it's clutter; digital dust accumulating. ### 3. Name properties like you'll have a thousand of them - **`snake_case`, always lowercase.** `date_published`, `related_projects`, `review_count`. - **Prefix families.** Dates start with `date_` (`date_started`, `date_due`, `date_published`), platform links with `url_` (`url_medium`, `url_substack`), health fields with `health_`. Prefixed families sort together, autocomplete together, and scan as a group. - **Plural for lists, singular for single values.** `authors`, `topics`, `related_goals` hold multiple values; `status`, `rating`, `priority` hold one. The name tells the shape. - **Descriptive beats short.** `health_sleep_total_minutes` is a mouthful, but the name carries the unit and the meaning, so no query ever guesses. These are the same principles software developers use to keep code readable, homogeneous, and maintainable. ### 4. Prefix ordered values with numbers ```yaml status: 10 - Backlog ``` An example task ladder: `10 - Backlog`, `20 - This Year`, `30 - This Quarter`, `40 - This Month`, `50 - This Week`, `60 - In Progress`, `70 - On Hold`, `80 - Done`. Why the numbers? Because plain text sorts alphabetically, and "Backlog, Done, In Progress" is a useless order. With numeric prefixes, every Base, every query, every Kanban column sorts by actual workflow position. The gaps between numbers (10, 20, 30...) allow inserting new states later without renumbering. ### 5. Define universal properties once Some fields belong on EVERY note: `created`, `updated`, `contexts`, `notes`, `description`, `title`, `topics`, `review_count`, `review_interval`, `last_reviewed`, etc. Universal properties give the whole vault a common backbone, whatever the note type. ### 6. Give each note type its own contract Every note gets a type: task, book note, person, project, daily note, article, quote... Each type declares which properties it carries. A book note carries `authors`, `isbn`, `pages`, `rating`, `date_started`, `date_finished`, `status`. A task carries `necessity`, `urgency`, `impact`, `effort`, `priority`, `status`, `date_due`, `related_projects`, `related_goals`. Thanks to this, a note's structure can be relied upon without opening it. ## Best practices - **Metadata goes way beyond tags.** Tags classify; properties carry values. The moment you want to store a date, a number, a status, or a link, you need properties. Tags answer "what kind of note is this and what topics does it touch?" (type tags like `type/task` plus taxonomy tags); properties hold everything with a VALUE. Think of tags as breadcrumbs: rarely more than ten per note. And tags ARE a property (`tags`), so everything about properties applies to them too. See [[Why and how to tag notes in your PKM]]. - **Name tags and list values consistently.** Plural form, underscores between words, lowercase only, hierarchies (`psychology/positive_psychology`) when names start clashing. - **Nested tags roll up to their parents.** A note tagged `#obsidian/plugins` ALSO has the parent tag `#obsidian` for search, Dataview queries, and Base filters. A hierarchy gives two query levels for the price of one tag. - **Associate every note with time.** `created` and `updated` on each note give the knowledge base a timeline; file system creation dates rarely survive syncs, migrations, and restores. - **Never maintain lists by hand.** Any manually curated list of notes (reading lists, overviews, indexes) will rot. Store the information as properties and let queries build the lists (e.g., via the [[Dataview Serializer plugin for Obsidian]]; recommended for [[Map of Content (MoC)|Maps of Content]]). - **Keep the why, the context, and the sources.** A `description` field, a `source` link, an `authors` list. - **Don't overthink it.** No need for the perfect schema on day one: `created`, `updated`, and one `status` field on the most-touched notes. Everything else can grow from there. Structure can grow later; consistency can't be retrofitted. - **Statuses matter.** Consider the lifecycle of each note type (actions, articles, videos, ...) and track state where it makes sense. ## Never type metadata by hand: templates Manual metadata entry fails for two reasons: you forget, and you improvise. With the [[Templater plugin for Obsidian|Templater]] plugin, every note type gets a template that fills in the frontmatter at creation time: the right properties, the right defaults, the current timestamp, even the right folder. A minimal example of what a template inserts: ```yaml --- created: 2026-07-15T10:00 updated: 2026-07-15T10:00 status: 10 - Backlog tags: - type/task --- ``` Never type `created` by hand. The template does it, gets the format right (ISO 8601, sortable), and never forgets. The `updated` field can be maintained automatically with the [[Update time plugin for Obsidian]]. Templates cover the notes you CREATE. The [[Obsidian Web Clipper]] covers the ones you CAPTURE: when clipping an article from the Web, the official clipper fills in the properties (source URL, author, publication date, title), so literature notes are born with full provenance. ## Keep it clean automatically: the Linter The [[Linter plugin for Obsidian]] enforces rules on notes automatically. For properties, three of its rules do most of the work: 1. **YAML Key Sort**: keeps properties in the same order on every note. Consistent ordering makes missing data jump out instantly. 2. **YAML Timestamp**: maintains `created` and `updated` fields, updating `updated` whenever the note changes. 3. **Format Tags in YAML**: fixes common syntax mistakes before they poison queries. The Linter can run on file change, so every touched note gets tidied automatically. Two practical warnings: configure backups BEFORE configuring the Linter (it can modify every file in the vault), and exclude archive folders. ## The payoff: the vault becomes a database [[Obsidian Bases]] turns any set of notes into live views: tables, card galleries, calendars, kanban boards, etc. A Base doesn't store anything; it READS the notes' properties. The quality of the Bases depends fully on the quality of the metadata. Properties plug into Bases at three levels: 1. **Filters** decide which notes are in. Every condition is a test on metadata: `status` is "Reading", `rating` is at least four stars, `date_due` is before next Friday. Clean enumerated values make filters trivial; messy ones make them impossible. 2. **Columns** display properties. Every column in a Base table IS a property (and values can be edited right in the view, which writes them back into the note). 3. **Formulas** create VIRTUAL properties: computed columns that live in no note but combine the real ones on the fly. Example: ``` days_until_due = (date(date_due) - today()) / duration("1d") ``` No note stores `days_until_due`; it exists only in the view, always current. A second formula can bucket it into "🔴 Overdue / 🔥 Today / 📅 This Week", and a dashboard sorts itself by urgency. Store the raw facts in properties, and let formulas derive everything else. Embedded Bases can reference the current note through the `this` keyword, so a single saved view adapts to wherever it's embedded (a Base in an author's note filtered on `this` lists that author's books). And performance holds up across 20,000+ notes. ![[Obsidian Bases - Cards view.png]] Caption: An Obsidian Base showing notes as cards, every column and cover powered by properties With a clean schema in place, this yields for free: a reading dashboard (book notes filtered by `status`, sorted by `rating`, with covers), a life tracking system (daily-note health properties turned into trend views), and [[Kanban Boards]] where dragging a card writes the new `status` straight back into the note. Clean properties are the whole game. ## Querying properties: Dataview, DataviewJS, and Templater The [[Dataview plugin for Obsidian|Dataview plugin]] provides a query language over properties, right inside a note: ``` TABLE authors, rating, date_finished FROM #type/book WHERE status = "Read" AND date_finished >= date(2026-01-01) SORT date_finished DESC ``` Dropped into any note, that block yields a live table of every book finished this year. Change the `WHERE` clause for overdue tasks, stale notes (`updated` older than a year), drafts waiting for review... This is the "never maintain lists by hand" principle with an engine behind it. Two Dataview specifics: - An EMPTY property is not the same as a missing one: `WHERE rating != null` still matches notes with a blank `rating:` line; write `WHERE rating AND rating != null` for actual values. - Dataview also supports inline fields in the note body (`key:: value`), but ONLY Dataview sees them: the property editor ignores them, Bases can't query them, and every other tool skips them. Keep everything in the front matter, where the whole ecosystem can read it. One catch: Dataview results are rendered on the fly, so they're invisible to the graph, to backlinks, and to anything published. The [[Dataview Serializer plugin for Obsidian|Dataview Serializer plugin]] takes a Dataview query and writes the RESULTS into the note as real Markdown: the links are real, they show up in the graph, and they survive publishing. ![[Dataview Serializer 2.0 - Powerful Queries Without Sacrificing Data Portability (Article) - example.png]] Caption: The Dataview Serializer at work; the query lives in a comment, and the results are written into the note as a real Markdown table with real links When queries aren't enough: DataviewJS blocks give JavaScript over properties (compute, aggregate, render anything), and [[Templater plugin for Obsidian|Templater]] scripts can READ and WRITE frontmatter through Obsidian's API. Example: a publish template that compares the actual list of published files against every note's `public_note` frontmatter, fixes drift, and runs the Dataview Serializer. The vault can ACT on its own properties. ## From properties to applications ### Action system Goals, plans, projects, and tasks as four note types, all carrying the same prioritization properties: ```yaml necessity: 10 - MUST # MoSCoW: MUST / SHOULD / COULD / WONT urgency: 20 - Soon # Now / Soon / This Year / Next Year / Future impact: 10 - High # High / Medium / Low effort: 20 - Medium # Small / Medium / Large / Huge priority: 99 - TBD # manual override when I disagree with the math status: 60 - In Progress progress: 40 time_estimate: 90 # minutes for tasks; goals and projects use time_estimate_days ``` Details worth stealing: - **`99 - TBD` as the default for every scoring field.** Unscored items sort last and stay visibly unscored, instead of silently pretending to be low priority. - **The status ladder IS the workflow.** Tasks flow `10 - Backlog` → `50 - This Week` → `60 - In Progress` → `80 - Done`. Goals and projects have their own lifecycle: `99 - Idea` → `20 - Planned` → `30 - Active` → `60 - Completed` (or `70 - Abandoned`). Because the values are enumerated and typed, every tool honors the same lifecycle. The workflow is defined ONCE, in the schema. - **Relationship properties create the chain of purpose.** Tasks carry `related_projects`, projects carry `related_goals`, plans tie into both. Any task can answer "which goal does this serve?" by following two links. On top sits ONE Base with ~20 views (tables, "Current Focus", calendar and list views via the [[TaskNotes plugin for Obsidian|TaskNotes plugin]], Kanban views). Its most useful column is a formula no note stores: ``` priority_score = necessity × urgency + impact − effort ``` Fill in four honest fields per item, and the ranking computes itself, live, across hundreds of actions. When the ranking feels wrong, fix the inputs, not the list. The [[Kanban Action Planner plugin for Obsidian|Kanban Action Planner]] renders any Base view as a full planning application: Kanban columns generated from the status values, swimlanes, due dates, filtering, triage mode. Dragging a card from "This Week" to "In Progress" writes `status: 60 - In Progress` into the note's frontmatter. The board doesn't have its own database: the properties ARE the database. ![[2026-06-30 - Kanban Action Planner plugin for Obsidian - board.png]] Caption: The Kanban Action Planner rendering the action system as a board; every column is a status value ![[obsidian-properties-application-stack.jpg]] Caption: The full stack: typed properties as the schema, status ladders and formulas as the logic, Bases and Kanban views as the interface Typed properties with enumerated values: a database schema. Status ladders and computed scores: business logic. Base views and a Kanban plugin: the user interface. An entire application, with clearly-defined workflows, built on top of plain Markdown files. ### Publishing pipeline Every article is a note of type "article", and its properties ARE the publishing workflow: ```yaml status: 70 - Draft Ready published: false date_published: date_updated: excerpt: Properties are the difference between a pile of Markdown files and... slug: the-complete-guide-to-obsidian-properties url: url_medium: url_substack: url_linked_in: url_podcast: url_x: ``` - **`status` is the editorial ladder**: `99 - Idea` → `10 - Backlog` → `60 - In Progress` → `70 - Draft Ready` → `80 - Edited` → `90 - Published`. "What's ready to edit?" is a saved query, not a mental checklist. - **The `url_*` family is a cross-posting checklist.** One field per platform. An EMPTY `url_medium` literally means "not cross-posted to Medium yet". The metadata records what's done AND shows what remains. - **`excerpt` and `slug`** feed the publishing automation. ### Reading library Each book is one note of type "book": ```yaml title: Atomic Habits subtitle: An Easy & Proven Way to Build Good Habits & Break Bad Ones authors: - "[[James Clear]]" status: Read rating: ★★★★★ pages: 320 isbn: 9780735211292 publisher: Avery published_on: 2018-10-16 date_started: 2023-01-05 date_finished: 2023-02-11 cover: https://... categories: - Self-help ``` Two things to notice. First, `authors` holds LINKS to person notes, so every book connects to its author, and every author's page lists their books through backlinks. Second, the reading statuses (`To Read`, `Reading`, `On Hold`, `Read`, `To Read Again`, `Abandoned`, `Reference`) have NO numeric prefixes, unlike task statuses: reading status is only filtered on, never sorted. Prefix the values that need an order, and leave the rest human-readable. A Books Base then provides: a Reading view (current stack), To Read queries (the anti-library), Read This Year (reading stats with zero bookkeeping), and card galleries with covers pulled straight from the `cover` property. The [[Bookshelf plugin for Obsidian|Bookshelf plugin]] renders those same book notes as an actual bookshelf. ![[Obsidian Starter Kit - Screenshots - Books base (cards).png]] Caption: A Books Base showing book notes as cards, with covers, ratings, and reading status pulled from properties Finishing a book means flipping two properties and adding a rating; every view updates itself. That's the entire maintenance burden. ### Life and health tracking A daily-note type can carry 100+ properties (e.g., 93 starting with `health_`): ```yaml health_sleep_total_minutes: 432 health_sleep_score: 82 health_resting_heart_rate: 52 health_heart_rate_variability_overnight_average: 58 health_stress_average: 27 health_body_battery_at_wake: 88 health_training_readiness: 74 health_exercise_steps: 11250 health_exercise_runs: - 8.2km in 44:10, avg HR 148 health_nutrition_meals: - ... health_medications: - health_symptoms: - ``` Watch data syncs into these properties automatically. Alongside the health fields sit life ones: `wins`, `gratitude`, `decisions`, `key_events`, `anecdotes`, `reflections`. The day's story in queryable form. A Health Base turns the properties into trend views ("which days did I sleep badly, and what did those days have in common?"), and the [[Life Tracker plugin for Obsidian|Life Tracker plugin]] visualizes a year at a glance. The data is owned forever, in plain Markdown files, and can be correlated with anything else in the vault. ![[Life Tracker plugin for Obsidian - with trends.png]] Caption: The Life Tracker plugin visualizing a year of daily-note health properties, with trends It's always the same pattern: define the schema once for a note type, define a template, fill the properties consistently (or let automation fill them), and create queries and/or Bases to leverage the information. ## Properties and AI Tags can classify notes, but they can't hold values: you can't sort tags by date, sum them, or put them in a column. As a vault grows, semantic weight moves out of tags and into properties, because properties are typed, queryable data. Tags end up doing exactly one job (routing notes by type and zone); properties do everything else. Metadata upkeep used to be a tax. AI changed the economics: 1. **The cost collapsed.** Agents fill in missing properties, fix malformed ones, and validate notes against each type's schema (the [[Obsidian Starter Kit plugin for Obsidian|Obsidian Starter Kit plugin]] exports every note type definition to files a CLI and AI can read). 2. **The payoff exploded.** Properties are how AI understands a vault. An agent that reads `status: 60 - In Progress` on a task, `rating: ★★★★★` on a book, `related_goals` on a project doesn't have to guess what notes mean. The schema tells it. Agents can plan the week from task properties, pull reading stats from book properties, build new Bases on request. None of that works well at scale with an untyped pile of Markdown. This extends to development work: project notes carrying a `repositories` property let an AI assistant go from "let's work on X" to the right codebase, with the project's goals, status, and open tasks as context: ```yaml repositories: - https://github.com/DeveloPassion/knowii-voice-ai - https://github.com/DeveloPassion/knowii-voice-ai-docs ``` None of this requires Obsidian to be open: the [[Obsidian CLI]] reads and writes properties and runs searches straight from the terminal. Properties as an interface, all the way down. ![[obsidian-properties-ai-metadata-loop.jpg]] Caption: The virtuous loop: the schema makes metadata reliable, reliable metadata makes AI useful, and AI maintains the metadata The loop closes: schema makes metadata reliable, reliable metadata makes AI useful, and AI keeps the metadata reliable. ## Getting started 1. **Enable the Properties core plugin** (Settings → Core plugins). 2. **Pick ONE note type you create often.** Books, meetings, projects, whatever. 3. **Give it 3 to 5 properties.** A `status`, a date or two, maybe a `rating`. Right types. `snake_case`. Numeric prefixes on ordered values. 4. **Make a template** so new notes include the properties at creation time. 5. **Install the Linter** with YAML Key Sort and YAML Timestamp (or the [[Update time plugin for Obsidian]]). 6. **Build one Base on top.** One filter, one table. Then live with it for a month, and only add a property when a question demands it. Start simple. Structure can grow later; consistency can't be retrofitted, so start consistent instead. ## References - Obsidian Properties documentation: https://help.obsidian.md/properties - Obsidian Bases documentation: https://help.obsidian.md/bases - YAML specification: https://yaml.org/spec/1.2.2/ - Jekyll front matter documentation (where the convention comes from): https://jekyllrb.com/docs/front-matter/ - Obsidian Linter plugin documentation: https://platers.github.io/obsidian-linter/ - Dataview plugin documentation: https://blacksmithgu.github.io/obsidian-dataview/ ## Related - [[A property is a promise]] - [[Metadata is an interface]] - [[Discipline doesn't scale, automation does]] - [[Store raw facts, derive the rest]] - [[The Complete Guide to Obsidian Properties (Article)]] - [[How I Turned 20,000 Notes Into Live Dashboards With Obsidian Bases (Article)]] - [[How I Turned My Obsidian Notes Into Kanban Boards (Article)]] - [[How I Manage All My Tasks Inside Obsidian with the TaskNotes Plugin (Article)]] - [[Supercharge Your PKM Workflow with the Obsidian Web Clipper (Article)]] - [[Why and How to Tag Your Notes (Article)]] - [[Obsidian Starter Kit - Reference - Note Properties]] - [[Obsidian]] - [[Obsidian Bases]] - [[Obsidian Web Clipper]] - [[Obsidian CLI]] - [[Obsidian Publish]] - [[Obsidian Starter Kit]] - [[Obsidian Starter Kit plugin for Obsidian]] - [[Properties view core plugin for Obsidian]] - [[Metadata Menu plugin for Obsidian]] - [[MetaEdit plugin for Obsidian]] - [[Fold Properties By Default plugin for Obsidian]] - [[Templater plugin for Obsidian]] - [[Linter plugin for Obsidian]] - [[Update time plugin for Obsidian]] - [[Expander plugin for Obsidian]] - [[Dataview plugin for Obsidian]] - [[Dataview Serializer plugin for Obsidian]] - [[TaskNotes plugin for Obsidian]] - [[Kanban Action Planner plugin for Obsidian]] - [[Bookshelf plugin for Obsidian]] - [[Life Tracker plugin for Obsidian]] - [[Yet Another Markup Language (YAML)]] - [[File over app principle]] - [[Why and how to tag notes in your PKM]] - [[When you take a note, you need to add a minimum of metadata]] - [[Templates boost PKM consistency]] - [[Characteristics of good notes]] - [[Map of Content (MoC)]] - [[Kanban Boards]]