Make Tana Supertags 🦸 in Obsidian using the Metadata Menu Plugin

TL;DR

Install and enable the Metadata Menu community plugin in Obsidian to create schema-driven metadata editing.

Briefing Cornell Notes

Briefing

Obsidian can mimic Notion-style “super tags” by using the Metadata Menu community plugin, letting users define structured metadata (fields) for notes and edit those fields through a clean UI—whether clicking a link, working in a table, or editing inline. The core move is creating a “file class” schema: a tag name (like `person`) becomes the blueprint for what metadata a note with that tag must contain, including field types such as text, select lists, multi-selects, booleans, numbers, links, and dates.

Setup starts in Obsidian Settings → Community plugins, where the Metadata Menu plugin is installed and enabled. The plugin’s key feature is “file class.” Users create a folder to store file classes, then add a file class named to match the tag they want to use (for example, a `person` file class). Once the file class exists, fields are added by right-clicking the class and creating new fields. Each field can be configured to accept any value (free text), a multi-select list (with predefined options like “Obsidian,” “anime,” or “coding”), or a boolean (true/false for something like “friend”). The result is a consistent metadata schema that appears automatically when a note is tagged with the file class name.

After defining fields, the workflow becomes practical: create a note titled with the tag (e.g., `#person`) and the plugin surfaces the metadata UI. Users can add fields in a chosen location within the note, then fill values directly—either by typing field names (with auto-suggestions) or by selecting from configured options. Editing also becomes “link-aware.” If another note links to a `person` note, the linked note can expose an interface to edit its metadata right from the link, reducing the need to open and manually edit the target note.

For power users, the plugin integrates with Dataview and Dataview JS to edit metadata from tables. A Dataview table can list fields like address, interests, and friend across all notes tagged with `person`, while filtering out unwanted folders such as `templates` and `file class` directories. With JavaScript query support enabled, the table can render editable controls—using a wrapper function that binds each row’s page and field to an interactive editor.

Beyond basic organization, the plugin supports more advanced metadata logic. Lookup queries can pull metadata from other notes and compute results—such as averaging ages across multiple `person` notes for habit tracking or analytics. Schemas can also be combined by using multiple file classes (e.g., one for `person` and another for `co-worker`) to attach different sets of fields like working hours or preferences. The overall payoff is a flexible, schema-driven system that goes beyond folders and simple tags, bringing structured “super tag” behavior to Obsidian with minimal friction.

Cornell Notes

Metadata Menu turns Obsidian tags into structured “super tags” by defining file class schemas. A file class (named to match a tag like `person`) specifies which metadata fields a note should have and what types they accept—free text, multi-select lists, booleans, dates, links, and more. Once fields are defined, notes tagged with that file class automatically get a UI for editing metadata, including editing from links and from Dataview tables. With Dataview JS enabled, tables can render interactive editors for fields like address, interests, and friend across many notes. Lookup queries and multiple file classes enable computed metadata and richer cross-note workflows.

What is a “file class” in Metadata Menu, and how does it relate to tags?

A file class is a schema that defines the metadata fields for notes. Its name is tied directly to a tag: if a file class is named `person`, then notes that use the `person` tag get the corresponding metadata structure. The setup involves creating a file class folder, setting the file class path, adding a file class (e.g., `person`), and enabling the option that allows typing the tag with the same name as the file class.

How do field types work, and what examples were used?

Fields can be configured to accept different input types. The transcript demonstrates: (1) a free-text field like `address` that accepts any value (e.g., “Earth”); (2) a multi-select field like `interests` with predefined options (e.g., “Obsidian,” “anime,” “coding”); and (3) a boolean field like `friend` that accepts true/false (e.g., `false`).

How can metadata be edited without opening the target note directly?

Metadata Menu can surface editing controls when a note is linked. If a note links to a `person` note (e.g., a link to Barack Obama), the linked entry can present an interface to edit its fields from the link itself. The transcript also shows editing from Dataview tables, where each row corresponds to a note and fields can be changed inline.

What role does Dataview JS play in table-based editing?

Dataview JS enables interactive editing inside Dataview tables. The workflow includes enabling JavaScript queries, then writing a Dataview JS query that builds a table with columns for fields (file name/link, address, interests, friend). A wrapper function is used to bind each row’s page and the specific field so the table can render editable controls. Filtering is applied to exclude paths containing `templates` and `file class`.

What are lookup queries used for?

Lookup queries pull metadata from other notes and can compute derived values. The transcript references a developer example where ages from multiple `person` nodes are gathered and averaged. This is positioned as useful for analytics-style tracking, such as calculating averages for daily habits.

How can multiple schemas be combined for richer note types?

Instead of one schema for everything, users can create multiple file classes—such as one for `person` and another for `co-worker`. Each class can define different fields (e.g., `co-worker` might include working hours or tolerance levels), allowing notes to carry different structured metadata depending on which tags they use.

Review Questions

When creating a `person` schema, what must be true for a note to automatically show the metadata UI?
How does enabling Dataview JS change what a Dataview table can do with metadata fields?
Give one example of how multi-select and boolean fields differ in how values are entered.

Key Points

1
Install and enable the Metadata Menu community plugin in Obsidian to create schema-driven metadata editing.
2
Create a “file class” whose name matches the tag you want to use (e.g., `person`) so notes with that tag get the right fields.
3
Define fields inside the file class with specific types such as free text, multi-select lists, and booleans (true/false).
4
Insert metadata UI into notes by adding the field at a chosen location; field names can auto-suggest as you type.
5
Edit metadata directly from links to tagged notes, reducing the need to open each note manually.
6
Use Dataview JS to render editable metadata controls inside tables, with filters to exclude `templates` and `file class` folders.
7
Leverage lookup queries and multiple file classes to compute derived values and support different note categories with different field sets.

Highlights

File classes turn a single tag into a structured metadata schema, so `#person` can automatically bring up address, interests, and friend fields.

Metadata editing can happen from links: clicking a linked `person` note can expose field controls without leaving the current context.

Dataview JS makes metadata fields editable inside tables, enabling bulk updates across many notes with filters.

Lookup queries enable computed metadata across notes, such as averaging ages across all `person` entries.

Topics

Metadata Menu
File Classes
Dataview JS
Multi-Select Fields
Lookup Queries