Get AI summaries of any video or article — Sign up free
An Introduction to Dataview - Part 1 thumbnail

An Introduction to Dataview - Part 1

6 min read

Based on Obsidian Community Talks's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Dataview can query an Obsidian vault like a database, generating lists and tables from note content and metadata.

Briefing

Dataview turns an Obsidian vault into a queryable “database,” letting users filter, sort, and extract information from their notes using a dedicated query language. The practical payoff is immediate: instead of manually maintaining lists, tables, and indexes, users can generate them on demand from note content and metadata—while keeping the results uncluttered in Obsidian’s graph because Dataview-generated links aren’t treated as real Obsidian links.

A core requirement for getting useful results is metadata—information about the notes themselves. The session breaks metadata into two categories: inherent metadata that comes with the data (like image dimensions and timestamps) and manually added metadata stored in each Markdown note. For Dataview, the manual layer typically lives in YAML frontmatter at the top of a note, structured as key–value pairs enclosed by three dashes. YAML lists are supported in two equivalent forms: inline lists using square brackets and comma-separated values, or indented lists using dashes on separate lines. Spacing matters for indented YAML (tabs can invalidate the frontmatter), and Obsidian will flag invalid YAML in preview.

Dataview relies on several metadata data types, including numbers, strings (quoted), lists (including mixed-type lists), and dates. Dates can be specified with varying granularity—year/month/day with optional time—and Dataview can also interpret compact numeric formats (for example, without dashes). A special case is “link-like” values: Obsidian may not treat YAML link text as clickable links, but Dataview can still resolve them in queries, which becomes useful for building structured outputs.

Beyond user-defined frontmatter, every note exposes implicit fields Dataview can query, such as file.name (the note title), file.path, file size in bytes, and timestamps like creation/modification time. If a note title contains a date, Dataview can extract it via file.day. Tags also become queryable through file.tags, including nested tags represented as arrays.

With the metadata foundation in place, the talk moves into Dataview’s query building blocks. The simplest output is a list: “list from” selects notes based on criteria like tags, folder paths, or link relationships (incoming via links-to a specific note, outgoing via links leaving a note). Logical operators refine selection: intersection (tag A AND tag B), union (tag A OR tag B), and negation (exclude notes with a tag). String concatenation can format list items (e.g., combining file paths with emojis), and nested list outputs can pull structured fields like authors from metadata.

More advanced filtering uses a where block, which applies comparison operators (greater than, equal, not equal, etc.) against metadata fields and inherent properties. Examples include selecting notes modified within the last day, excluding a specific filename, and finding notes missing a due date field (empty values behave like absent fields). For presentation, Dataview supports tables that can display multiple metadata columns, plus sorting and flattening list-valued fields into separate rows. Group by organizes results into nested structures based on a field such as assignment intensity, enabling follow-on queries through the grouped “rows” object.

Finally, the session highlights real-world use cases: building dynamic tables of contents, generating assignment dashboards (due soon, completed, grouped by intensity), finding untagged notes by checking tag counts, and creating snippet-style showcases that Obsidian can’t embed via iframe. Limitations also surface—Dataview-generated “links” don’t appear in graph view and can’t be used as inputs to other Dataview queries, and there’s no direct file.links property for general “incoming link” queries across arbitrary sets. The session ends with Q&A, including requests for better debugging, query explanation, and features like alias-based display and nested-query workflows.

Cornell Notes

Dataview lets users treat an Obsidian vault like a database: notes become records that can be queried to produce lists and tables. The key enabler is metadata—YAML frontmatter with well-formed key–value pairs and typed values (numbers, strings, dates, lists). Dataview also exposes implicit fields such as file.name, file.path, file size, timestamps, and file.tags (including nested tags as arrays). Queries start with “list from” to select notes by tags, folders, or link relationships, then use where blocks to filter by comparisons on metadata and inherent properties. Tables, sorting, flattening, and group by turn raw selections into structured outputs like assignment dashboards and dynamic indexes.

Why does Dataview depend so heavily on metadata, and what’s the difference between inherent and manually added metadata?

Inherent metadata comes from the underlying data itself (e.g., a photo’s dimensions or timestamps). Manually added metadata is stored in each note—typically YAML frontmatter—so Dataview has consistent fields to filter and display. The talk emphasizes that YAML frontmatter uses three dashes to open/close the block, then key–value pairs like key: value. YAML lists can be written inline with square brackets or as indented lists using dashes, and invalid spacing (like tabs) can break YAML parsing.

What implicit fields can Dataview query without you defining them in YAML?

Dataview provides implicit properties such as file.name (the note’s title as a string), file.path, file size in bytes, and creation/modification times. It can also extract file.day when the note title contains a date. Tags are available via file.tags as an array; nested tags using forward slashes become nested levels stored in the array so queries can target sub-levels.

How do “from” and logical operators change which notes appear in a Dataview list?

A “list from” clause selects notes by criteria such as tags, folder paths, or link relationships (notes that link to a specific note, or notes that a note links out to). Logical operators refine selection: intersection requires both tags (tag A AND tag B), union returns notes matching either condition (tag A OR tag B), and negation uses a minus sign to exclude notes with a given tag. Brackets can control order of operations when combining multiple conditions.

What does a where block add, and how can it filter by time or missing fields?

A where block further filters the results from the from clause by applying comparison operators to metadata fields. Examples include selecting notes where file.mtime is greater than “current date minus one day” (modified within the last day). It can also exclude specific filenames using file.name != 'Exact Name'. For missing fields, the talk notes that empty values behave like absent fields—for instance, selecting assignments where due date is not set.

How do table, sort, flatten, and group by differ in how results are presented?

A table outputs multiple columns of metadata per note and can include several fields separated by commas. sort orders results by a chosen field (which can be a field not shown as a column). flatten “unrolls” list-valued fields so each list element becomes its own row, repeating the note context. group by clusters results into nested groups based on a field value (like assignment intensity), producing a grouped structure accessed via a rows object for follow-on queries.

What are key limitations mentioned for link-based workflows?

Dataview-generated links (produced by list/table outputs) aren’t treated as real Obsidian links, so they don’t appear in graph view and can’t be used as inputs to other Dataview queries. Additionally, there’s no general file.links property for arbitrary incoming-link queries across a set; the talk describes this as a gap that prevents certain “notes that link to notes with tag X” queries.

Review Questions

  1. How would you structure YAML frontmatter for a Dataview query that needs a list of authors and a date field? Include the key–value and list formatting approach.
  2. Given a set of notes tagged “university,” how would you use from plus where to return only those modified within the last 7 days?
  3. What’s the practical difference between using list output versus table output when you want multiple metadata fields and sorting?

Key Points

  1. 1

    Dataview can query an Obsidian vault like a database, generating lists and tables from note content and metadata.

  2. 2

    YAML frontmatter is the main way to add queryable metadata; correct YAML formatting (especially indentation and spacing) is essential.

  3. 3

    Dataview supports typed metadata including numbers, strings, lists, and dates with varying granularity, plus date arithmetic in where blocks.

  4. 4

    Implicit fields like file.name, file.path, file.mtime, and file.tags are available for filtering and display without extra YAML.

  5. 5

    “from” selects candidate notes (by tags, folders, or link relationships), while “where” applies comparison operators to narrow results further.

  6. 6

    Tables, sorting, flattening, and group by provide different ways to present and restructure query results for dashboards and indexes.

  7. 7

    Link-based workflows have limitations: Dataview-generated links don’t become real Obsidian links, and there’s no general file.links property for incoming-link queries across arbitrary sets.

Highlights

Dataview-generated links don’t clutter Obsidian’s graph because they aren’t treated as real Obsidian links, even though they appear in query output.
YAML indented lists require precise spacing (tabs can invalidate frontmatter), and Obsidian flags invalid YAML in preview.
where blocks can filter by time using date arithmetic (e.g., “current date minus one day”) and can find notes missing fields by checking empty values.
group by creates a nested structure that’s accessed via a rows object, enabling follow-on queries over grouped results.
A major gap remains for incoming-link queries: there’s no general file.links property to support “notes that link to notes with tag X” across sets.

Topics