Tana Tutorial | How to use Semantic Functions in Tana

Semantic functions in Tana let users build bottom-up hierarchies and then retrieve data across those levels with recursive search. The payoff is practical: once fields are marked as “part of” a higher-level super tag, searches can “zoom out” from a specific node (like a university) to the broader entities it belongs to (city, state, country) without manually maintaining complex, top-down structures.

The tutorial starts by grounding the basics in two building blocks: super tags and fields. Super tags define the type of node—examples include University, City, State, or Tasks/Projects in a workspace. Fields define relationships and additional data about those nodes, functioning like key-value pairs (e.g., a university is in Los Angeles) and like spreadsheet columns when used in views (e.g., a book’s author, rating, and recommendation). A key distinction matters for usability: super tags and fields live in different menus, and the workflow differs when configuring each.

To unlock semantic behavior, fields must be configured with a field type and then enabled for semantic functions. The tutorial demonstrates this with a “manager” field on Projects: the field type can be set to something like “instance,” and then advanced options include toggling “field has semantic function.” Once enabled, the field can be set to a semantic relationship such as “part of.” The “instance of” choice also enforces structure: nodes must be predefined (or added automatically) under the referenced super tag, similar in spirit to data validation in Excel but more robust for a database-like workspace.

The University example turns this setup into a working hierarchy. Universities have a City field marked as “part of” (with City also marked as “part of” State, and State marked as “part of” Country). With that chain in place, a recursive search can start at universities and climb the hierarchy. The search uses components/recursive behavior so that specifying a higher-level entity (like Canada) filters universities correctly—even though the universities don’t directly store “country” as a field. The same logic works in reverse for state-level queries, such as finding all universities in California.

From there, the tutorial generalizes the pattern into three use cases. In project management, semantic “part of” links can mirror a work breakdown structure: subtasks are part of tasks, tasks part of projects, and projects part of initiatives. That enables queries for outstanding items at any level. In organizational or CRM-style setups, the same concentric-circle retrieval can filter employees or contacts by department or team. In software development, the approach supports mapping between epics, stories, features, and bugs so a search for a feature can pull related bugs (or related items across multiple intermediate levels).

A practical obstacle appears when relationships aren’t strictly linear—tasks might map to projects or to areas of responsibility. Defining separate fields at every level can become burdensome. The tutorial’s workaround is to use a single “relates to” relationship field (built as an instance relationship and inherited across the workspace), so semantic “part of” can be defined once and applied recursively. The result is a repeatable structure that reduces setup overhead while making multi-level retrieval straightforward through recursive search.