How to Use Obsidian DataView: A Complete Beginner's Guide

TL;DR

Define note metadata using front matter (three dashes) so DataView has fields to query.

Briefing Cornell Notes

Briefing

Obsidian DataView turns a personal note vault into a queryable database—letting users generate live lists, tables, calendars, and task views based on note metadata and file properties. The core requirement isn’t just installing the plugin; it’s understanding front matter (metadata) and then writing DataView queries that match that metadata precisely. Once that foundation is in place, DataView can replace manual searching with structured, filterable views for reading lists, processing pipelines, and any other knowledge workflow.

The guide starts by showing practical examples: a dashboard where “nodes to process” and “recent nodes” are populated via DataView queries, plus reading lists that track books by status (e.g., currently reading, completed, future). To make those queries work, each note needs metadata. In Obsidian, metadata is stored as front matter—written between three dashes at the top of a note. The transcript walks through an example front matter block such as status: completed and author: me, emphasizing that DataView is strict about correct field names and casing. If the metadata format is wrong or a query references the wrong key (for example, author vs Author), DataView returns errors or empty results.

Installation and setup follow: users enable the DataView plugin from Settings → Community Plugins, and the guide recommends turning on inline JavaScript queries and JavaScript queries for future flexibility. With DataView installed, the user creates query blocks using triple backticks and the syntax data view … (then chooses a query type). The basics include four main output formats: list, table, tasks, and calendar. Lists are simple and headerless; tables support multiple columns and show missing metadata as dashes. Tasks pull items labeled as tasks from notes, while calendar views can be generated from file creation time or file modified time, displaying one dot per note on each date.

The “advanced” section focuses on query power: the from clause narrows the search scope, while the where clause filters results. Examples include pulling notes only from a specific hashtag (from #book), restricting to a folder (from "003 resources"), querying within subfolders using a slash path, and filtering by link relationships using from outgoing or from "[[Some Note]]"-style targeting. Filtering uses where conditions such as where status is completed, where status does not contain completed (via negation), and where contains rating to select books by star ratings. Sorting is handled either in-query (e.g., sorting by file modification time in ascending or descending order) or through the separate Sortable plugin, which adds clickable column headers to reorder results without rewriting code.

Finally, the guide covers limiting results (limit 5, limit 7, etc.) to keep dashboards fast and readable. The takeaway is straightforward: define consistent metadata with front matter, then use DataView’s from/where/sort/limit mechanics to build a personal knowledge database that stays automatically updated as notes change.

Cornell Notes

Obsidian DataView can turn a notes vault into a live database by generating views from metadata and file properties. The key prerequisite is front matter: metadata written at the top of notes using three dashes, with field names and casing that match DataView queries exactly. DataView supports multiple output formats—list, table, tasks, and calendar—so users can build dashboards, reading trackers, and date-based note maps. Advanced queries use from to restrict scope (hashtags, folders, links) and where to filter (status, ratings, negation). Sorting can be done in-query or with the Sortable plugin, and limit controls how many results appear.

Why does DataView often return empty results even when notes “look” correct?

DataView is strict about metadata keys and formatting. If a note’s front matter uses a different field name or casing (e.g., author vs Author, total_pages vs total_pages vs total_page), the query won’t match and results can be blank or show errors. The transcript highlights this with examples where incorrect metadata names prevent pages from appearing in a table and where status filtering fails until the correct value (e.g., completed) is used.

What’s the practical difference between DataView list and table outputs?

A list output is headerless and simply enumerates matching notes. A table output supports multiple headers/columns, such as author, status, rating, and total pages. When a note lacks a requested metadata field, the table shows a dash (“-”) for that column, making missing data visible at a glance.

How do from and where work together in advanced DataView queries?

from narrows the universe of notes—such as notes with a hashtag (from #book) or notes inside a folder (from "003 resources"). where then filters within that narrowed set—such as where status is completed, where status does not contain completed (negation), or where contains rating for star ratings. Together they produce targeted views like “completed books in #book.”

How can a calendar view be generated, and what do the dots represent?

Calendar views use file time properties. Using file creation time shows a dot for each note created on a given date; using file modified time shows dots only on dates where notes were modified. The transcript’s example creates a note “today” and shows dots on the corresponding date, then demonstrates that only some notes were modified on a later date.

What are two ways to sort DataView results?

Sorting can be done in the DataView query itself by specifying a sort key and direction (ASC for ascending, DESC for descending). Alternatively, installing the Sortable plugin allows clickable headers in the DataView output—users can sort by rating, status, or file name without editing the query code.

When should users use limit in DataView queries?

limit keeps dashboards and tables readable and fast by restricting the number of returned rows. The transcript demonstrates limit 5, limit 7, and limit 2 to control how many matching notes appear in the result set.

Review Questions

What metadata fields and casing rules must be followed so DataView table columns populate correctly?
How would you write a DataView query to show only notes in a specific folder that have status set to completed, and then sort them by file modification time descending?
What’s the difference between using where status does not contain completed and where status is completed, and how would each affect the results?

Key Points

1
Define note metadata using front matter (three dashes) so DataView has fields to query.
2
Match DataView field names exactly, including uppercase/lowercase, to avoid empty or broken results.
3
Use list for simple headerless outputs and table when you need multiple metadata columns.
4
Use from to scope results (hashtags, folders, subfolders, link relationships) and where to filter by metadata values.
5
Generate calendar views from file creation time or file modified time to visualize note activity by date.
6
Sort results either in-query (ASC/DESC) or via the Sortable plugin’s clickable headers.
7
Use limit to cap result counts for cleaner dashboards and faster scanning.

Highlights

Front matter is the foundation: DataView queries depend on metadata written between three dashes at the top of each note.

Table outputs reveal missing metadata with dashes, making data quality issues easy to spot.

from #book + where status is completed is the pattern for building a “completed reading list” that updates automatically.

Calendar views can be driven by file creation time or file modified time, showing dots per note per date.

Sorting can be done in code or made interactive with the Sortable plugin.

Topics

Obsidian DataView
Front Matter Metadata
DataView Queries
Reading Lists
Sorting and Filtering