Obsidian - Getting Started with Dataview

TL;DR

YAML front matter (“top matter” between triple dashes) stores human-readable metadata that Dataview can query.

Briefing Cornell Notes

Briefing

Dataview turns an Obsidian vault into a queryable database by letting notes pull structured data from front matter and other files—then render the results as inline text or automatically generated tables. The payoff is practical: instead of retyping the same attributes across multiple places (especially in TTRPG workflows), users can store facts once in YAML front matter and have Dataview populate character sheets, wiki-style info boxes, and encounter planning views on demand.

The foundation is YAML front matter (the “top matter” section between triple dashes). Values stored there become variables—essentially named boxes holding data. Dataview’s inline expressions then inject those variables directly into the body of a note using syntax like “this.<variable>” (e.g., pulling a player’s name, race, class, or level into a template). In the TTRPG example, an info box is filled automatically from metadata fields, saving time and reducing copy/paste errors. The transcript also highlights multi-variable stacking (pulling multiple fields into a single rendered area) and encourages template-driven setups so users don’t have to memorize syntax.

From there, Dataview expands beyond front matter with inline JavaScript expressions (“inline JS”). Unlike inline expressions that mainly work with vault files and their variables, inline JS can pull in other computed values—such as the current time, the current file name, or the file path—demonstrating that Dataview can blend note metadata with dynamic logic. For deeper automation, Dataview query blocks generate tables by scanning a chosen folder and filtering results based on metadata.

The core query workflow is demonstrated by building a table of players from a specific folder (e.g., a party directory). The query defines the table columns (class, race, level, etc.) and filters notes by metadata such as role equals “player.” The transcript also contrasts equality filtering with substring matching using “contains,” noting that large queries can noticeably impact performance—sometimes causing the system to pause while results are processed. The practical guidance: keep queries scoped, avoid “return everything in the vault” patterns, and reuse templates for common query types.

Finally, Dataview JS queries show the most DM-friendly power: querying external JSON data used by TTRPG stat block tooling. A specialized example uses a stat block plugin’s data.json (and related initiative tracker data) to filter monsters by name content (e.g., “kobold”) and render a table with fields like HP, AC, attack/CR, and source. A key detail is linking: using dv.fileLink with monster.name creates clickable links to corresponding monster notes, even though the JSON itself doesn’t contain the note content—notes must exist separately for links to resolve. The result is a searchable, up-to-date monster roster that can feed encounter prep and reduce reliance on static “monster manual” style duplication.

Overall, Dataview’s value comes from combining front matter variables, inline expressions, query tables, and JS-powered access to structured data—while managing performance by limiting query scope and leaning on templates for repeatable syntax.

Cornell Notes

Dataview for Obsidian lets users treat a vault like a database: YAML front matter becomes queryable variables, inline expressions inject those values into notes, and Dataview query blocks generate tables from sets of notes. Inline JS expressions extend the system with computed or external values like current time, file name, and file path. For TTRPG use, Dataview queries can build player tables from folders by filtering metadata (e.g., role equals player or using contains). Dataview JS queries can also pull monster data from a stat block plugin’s data.json and render DM-facing tables, including clickable links via dv.fileLink when corresponding monster notes exist. Because large queries can slow or lock up the vault, scoping queries and using templates is strongly recommended.

How do YAML front matter variables become usable inside notes with Dataview?

YAML front matter sits at the top of a note between triple-dash lines. Each key/value pair (e.g., key: value, key2: value2) becomes a variable. Dataview inline expressions then reference those variables using a “this.<field>” style syntax. For example, if front matter includes name: josh, an inline expression like “my name is = this.name” renders “my name is josh” in preview. The transcript also shows pulling multiple fields (race, class, condition, level) into a wiki-style info box so the same metadata doesn’t need to be retyped in multiple locations.

What’s the difference between inline expressions and inline JS expressions in Dataview?

Inline expressions primarily pull values from vault note metadata and variables defined in front matter. Inline JS expressions (“JS” for JavaScript) go beyond that by enabling computed or contextual values not limited to front matter fields. The transcript’s examples include returning the current time, the current file’s name, and the file’s path. This makes inline JS useful when a note needs dynamic context or derived values rather than only stored metadata.

How does a Dataview query block generate a table from notes?

A Dataview query block defines a table schema (column names) and then selects a set of notes to scan, usually by pointing to a specific folder. The query then filters results using metadata conditions. In the example, the table columns include player class, race, and level, and the query scans a party folder. A filter like “where role equals player” ensures only player notes appear, excluding other entries (e.g., journey board notes) that share the same folder.

When should a user use “contains” instead of “equals” in Dataview queries?

Use “equals” when the metadata field must match exactly (e.g., role equals player). Use “contains” when the field may include additional text and the goal is to match a substring (e.g., filtering monsters or notes where a field includes a term like “kobold”). The transcript demonstrates that contains-based filtering works and contrasts it with equality filtering, emphasizing it as a powerful option for flexible matching.

How can Dataview JS queries power TTRPG monster tables, and what role does dv.fileLink play?

A Dataview JS query can read structured monster data from a stat block plugin’s data.json (and related initiative tracker data). The example filters monsters by whether their name contains a term (like “kobold” in lowercase) and renders a table with fields such as name, HP, AC, CR, and source. To make the table interactive, dv.fileLink monster.name is used so the monster name becomes a clickable link to a separate monster note. The JSON provides data, but the note content and existence are separate—if a note doesn’t exist (e.g., a monster without a corresponding note), the link won’t resolve until the note is created.

Why do large Dataview queries sometimes slow down or freeze Obsidian?

Dataview must scan and process the set of notes returned by a query, then sort and render results. Broad queries (like returning every monster across a large vault) can cause noticeable pauses or system lockups while computation finishes. The transcript advises scoping queries to smaller folders, avoiding “whole vault” result sets, and using smaller, targeted queries to prevent performance issues.

Review Questions

If a note’s YAML front matter includes role: player, how would a Dataview query filter to include only those notes?
What are three kinds of values the transcript claims inline JS expressions can return that inline expressions can’t reliably provide?
In a Dataview JS monster table, why might dv.fileLink create a broken or missing link for a monster name?

Key Points

1
YAML front matter (“top matter” between triple dashes) stores human-readable metadata that Dataview can query.
2
Inline expressions inject front matter variables into note text, enabling templates that auto-populate repeated fields like race, class, and level.
3
Inline JS expressions add dynamic or computed values such as current time, file name, and file path beyond simple metadata substitution.
4
Dataview query blocks generate tables by scanning a chosen folder and filtering notes using metadata conditions like role equals player or contains-based matching.
5
Large Dataview queries can noticeably slow or lock up Obsidian, so scoping queries and avoiding “return everything” patterns matters.
6
Dataview JS queries can pull monster data from a stat block plugin’s data.json and render DM-facing tables, including clickable links via dv.fileLink when matching monster notes exist.

Highlights

Dataview makes Obsidian vaults behave like queryable databases, turning front matter into live, table-driven views.

Filtering matters: role equals player isolates the right notes, while contains enables substring matching for more flexible selection.

The most powerful DM workflow comes from querying stat block data.json and rendering monster tables that can link back to separate monster notes.

Topics

Dataview Setup
YAML Front Matter
Inline Expressions
Dataview Query Tables
Dataview JS Monsters