Ontology, Knowledge Graphs & the Semantic Layer on Snowflake — The ConceptsSnowflake 上的本体论、知识图谱与语义层——概念篇
What they are, why they matter, and how they form a five-layer intelligence stack natively on Snowflake.它们是什么，为何重要，以及它们如何原生于 Snowflake 上构建起五层智能架构。
In the AI era, companies do not compete based on who stores the most data. They compete based on who understands how their business actually works.在人工智能时代，企业的竞争不再取决于谁存储的数据最多，而取决于谁能真正理解其业务运作方式。
Today, there is a significant gap. Facts live in databases. Definitions live in scattered documentation. AI systems are expected to somehow infer reality from raw tables. What we store and feed to AI today are tables, foreign keys, and often cryptic column names — yet we expect agents to understand our business.如今，存在着巨大的鸿沟。事实存在于数据库中，定义存在于零散的文档中。人工智能系统被期望能以某种方式从原始表中推断出现实。我们今天存储并提供给人工智能的是表、外键以及通常晦涩难懂的列名——但我们却期望智能体能够理解我们的业务。
In reality, businesses operate through objects and the relationships that connect them. In entertainment industry, these objects include actors, directors, movies, studios, awards, genres. An actor performs in a movie. A director helms a movie. A studio produces it. A movie wins an award. These connections are not simply elements of a database schema. They represent real-world entities and the relationships.实际上，业务是通过对象以及连接这些对象的关系来运作的。在娱乐行业，这些对象包括演员、导演、电影、制片厂、奖项和类型。演员在电影中表演，导演执导电影，制片厂制作电影，电影赢得奖项。这些联系不仅仅是数据库模式的元素，它们代表了现实世界中的实体及其关系。
The result of the gap between stored data and business meaning is complex SQL, duplicated logic, and AI systems that sound confident but often get things wrong. The goal is simple: move from joining rows to reasoning over concepts.存储数据与业务含义之间的鸿沟导致了复杂的 SQL、重复的逻辑，以及听起来自信但往往出错的人工智能系统。目标很简单：从连接行转向基于概念的推理。
Three architectural concepts close that gap — and when layered together on Snowflake, they form an intelligence stack that grounds AI reasoning in structured business knowledge:三个架构概念填补了这一鸿沟——当它们在 Snowflake 上分层组合时，就形成了一个将人工智能推理建立在结构化业务知识基础上的智能架构：
- Ontology — the blueprint that defines what is allowed to exist and how things can relate本体论——定义允许存在什么以及事物如何关联的蓝图
- Knowledge Graph — the building constructed from that blueprint, recording which relationships actually exist知识图谱——根据该蓝图构建的建筑，记录了哪些关系实际存在
- Semantic Layer — the query-time abstraction that translates business questions into correct SQL语义层——将业务问题翻译为正确 SQL 的查询时抽象
Ontology vs. Knowledge Graph: The Distinction That Matters本体论与知识图谱：至关重要的区别
An ontology is a blueprint. It defines that an Actor is a type of Person, that a Movie belongs to a Genre, and that an Actor can perform in a Movie. These are abstract rules that define what is allowed to exist and how things can relate. You define them once, and they rarely change.本体论是一份蓝图。它定义了“演员”是“人”的一种类型，“电影”属于某种“类型”，以及“演员”可以在“电影”中表演。这些是定义允许存在什么以及事物如何关联的抽象规则。你定义它们一次，它们很少发生变化。
A knowledge graph is the building constructed from that blueprint. Actor #A-1001 (Tom Hanks) performed in Movie #M-2045 (Forrest Gump), which was directed by Director #D-301 (Robert Zemeckis) and won Award #W-100 (Best Picture, 1995). These are concrete facts.知识图谱是根据该蓝图构建的建筑。演员 #A-1001（汤姆·汉克斯）在电影 #M-2045（《阿甘正传》）中表演，该电影由导演 #D-301（罗伯特·泽米吉斯）执导，并赢得了奖项 #W-100（1995 年最佳影片）。这些是具体的事实。
The blueprint says that Actors can perform in Movies and Movies can win Awards; the building records which specific actors, movies, and awards are connected.蓝图规定了演员可以在电影中表演，电影可以赢得奖项；而建筑记录了哪些具体的演员、电影和奖项是相互关联的。
One is a rule. The other is an instance.一个是规则，另一个是实例。
You need both, but they should remain separate. The blueprint evolves slowly and intentionally, while the building changes frequently. This separation provides both stability and flexibility.你需要两者，但它们应该保持独立。蓝图演进缓慢且经过深思熟虑，而建筑则频繁变化。这种分离提供了稳定性与灵活性。
Remember this: the ontology defines which relationships are allowed; the knowledge graph materializes which relationships actually exist.记住这一点：本体论定义了哪些关系是被允许的；知识图谱具体化了哪些关系是实际存在的。
1. Ontology — The Blueprint1. 本体论——蓝图
What Is an Ontology?什么是本体论？
What Is an Ontology?
An ontology is a formal, explicit specification of a shared conceptualization. In practical terms: it is a structured vocabulary that defines the entity classes, inheritance hierarchies, allowed relationships, and constraints that exist in a business domain.本体论是对共享概念化的正式、显式规范。通俗地说：它是一个结构化的词汇表，定义了业务领域中存在的实体类、继承层级、允许的关系以及约束条件。
If a data model tells you how data is stored, an ontology tells you what the data represents and what rules govern it.如果数据模型告诉你数据是如何存储的，那么本体论则告诉你数据代表什么以及什么规则支配着它。
Consider a movie database domain. A relational schema might have tables named MOVIE_DTL, CAST_REF, AWD_HIST, and STUDIO_MSTR. An ontology for the same domain would define:以电影数据库领域为例。关系模式可能包含名为 MOVIE_DTL、CAST_REF、AWD_HIST 和 STUDIO_MSTR 的表。而同一领域的本体论将定义：
- A Person is a root entity. An Actor is a type of Person. A Director is also a type of Person. A Producer is also a type of Person. This creates an inheritance hierarchy — like object-oriented programming, but for data. Importantly, a single Person can be an Actor and a Director and a Producer (Steven Spielberg, Clint Eastwood).“人”是一个根实体。“演员”是“人”的一种类型。“导演”也是“人”的一种类型。“制片人”也是“人”的一种类型。这创建了一个继承层级——就像面向对象编程一样，但针对的是数据。重要的是，同一个人可以既是演员，又是导演和制片人（如史蒂文·斯皮尔伯格、克林特·伊斯特伍德）。
- A Movie is a creative work with a title, release year, budget, runtime, and rating.“电影”是一种具有标题、发行年份、预算、时长和评级的创意作品。
- A Genre is a classification category (Drama, Action, Sci-Fi, Comedy).“类型”是一种分类范畴（剧情、动作、科幻、喜剧）。
- An Award is a recognition given at a ceremony, with a category and ceremony year.“奖项”是在颁奖典礼上给予的认可，具有类别和颁奖年份。
- A Studio is a production company that finances and distributes movies.“制片厂”是为电影提供资金并进行发行的制作公司。
- An Actor PERFORMED_IN one or more Movies. A Director DIRECTED one or more Movies. A Studio PRODUCED one or more Movies. A Movie BELONGS_TO one or more Genres. A Movie NOMINATED_FOR or WON an Award.演员“表演过”一部或多部电影。导演“执导过”一部或多部电影。制片厂“制作过”一部或多部电影。电影“属于”一种或多种类型。电影被“提名”或“赢得”奖项。
- Constraint: Every movie must have at least one Director. Rating must be between 0 and 10. Budget must be positive. A nomination’s ceremony year must be >= the movie’s release year.约束：每部电影必须至少有一位导演。评级必须在 0 到 10 之间。预算必须为正数。提名的颁奖年份必须大于或等于电影的发行年份。
The ontology captures meaning that no ERD diagram can express: what things are, how they relate, and what rules constrain them. You also define constraints on relationships — only an Actor can “perform in” a Movie; only a Studio can “produce” a Movie. When the business evolves with new entity types or relationships, updates are made through metadata. No schema rewrites or pipeline rebuilds are required.本体论捕获了任何实体关系图 (ERD) 无法表达的含义：事物是什么、它们如何关联以及什么规则约束它们。你还可以定义关系的约束——只有演员才能“在电影中表演”；只有制片厂才能“制作”电影。当业务随着新的实体类型或关系而演进时，更新是通过元数据完成的。无需重写模式或重建管道。
Ontology vs. Data Model本体论与数据模型
Ontology on SnowflakeSnowflake 上的本体论
Ontology on Snowflake is entirely configuration-driven. You are declaring concepts, not writing code. The ontology lives as metadata tables that define:Snowflake 上的本体论完全由配置驱动。你是在声明概念，而不是编写代码。本体论以元数据表的形式存在，定义了：
- Classes — what kinds of entities exist (Person, Actor, Director, Producer, Movie, Genre, Award, Studio)类——存在哪些实体（人、演员、导演、制片人、电影、类型、奖项、制片厂）
- Hierarchies — inheritance relationships (an Actor is a type of Person; a Director is also a type of Person; a Producer is also a type of Person)层级——继承关系（演员是人的一种类型；导演也是人的一种类型；制片人也是人的一种类型）
- Allowed relationships — which classes can connect and how (only an Actor can “perform in” a Movie; only a Studio can “produce” a Movie)允许的关系——哪些类可以连接以及如何连接（只有演员才能“在电影中表演”；只有制片厂才能“制作”电影）
- Constraints — business rules that must hold (rating between 0–10, budget must be positive, ceremony year >= release year)约束——必须遵守的业务规则（评级在 0-10 之间，预算必须为正数，颁奖年份 >= 发行年份）
This metadata is stored in standard Snowflake tables using VARIANT columns for flexible property definitions. When the business evolves — a new entity type like “Composer” or “Screenwriter” appears — you insert a metadata row. No new tables, no schema migrations, no pipeline rebuilds. The schema remains stable while meaning evolves above it.这些元数据存储在标准的 Snowflake 表中，并使用 VARIANT 列进行灵活的属性定义。当业务演进时——出现了像“作曲家”或“编剧”这样的新实体类型——你只需插入一行元数据。无需新表，无需模式迁移，无需管道重建。模式保持稳定，而其上的含义则不断演进。
A key design principle: facts are stored once, meanings are defined as configuration, and intelligence is orchestrated dynamically.一个关键的设计原则：事实只存储一次，含义作为配置定义，智能则动态编排。
2. Knowledge Graph — The Building2. 知识图谱——建筑
What Is a Knowledge Graph?什么是知识图谱？
A Knowledge Graph (KG) is the instantiated, connected representation of an ontology populated with real data. While the ontology declares “an Actor can perform in Movies,” the knowledge graph records that Actor #A-1001 (Tom Hanks) performed in Movie #M-2045 (Forrest Gump). While the ontology declares “a Movie can win Awards,” the knowledge graph records that Movie #M-2045 won Award #W-100 (Best Picture, Academy Awards 1995).知识图谱 (KG) 是本体论的实例化、连接表示，并填充了真实数据。虽然本体论声明“演员可以在电影中表演”，但知识图谱记录了演员 #A-1001（汤姆·汉克斯）在电影 #M-2045（《阿甘正传》）中表演。虽然本体论声明“电影可以赢得奖项”，但知识图谱记录了电影 #M-2045 赢得了奖项 #W-100（1995 年奥斯卡最佳影片）。
The physical design is radically simple. There are only two tables:物理设计非常简单。只有两张表：
- The Node table stores everything that exists — every actor, director, producer, movie, genre, award, studio节点表存储所有存在的事物——每个演员、导演、制片人、电影、类型、奖项、制片厂
- The Edge table stores every connection between entities — “performed in,” “directed,” “produced,” “belongs to genre,” “won award”边表存储实体之间的每个连接——“表演”、“执导”、“制作”、“属于类型”、“赢得奖项”
Both use VARIANT columns for flexible properties. An Actor is a node. A Movie is a node. “Performed in” is an edge connecting them. An Award is a node. “Won” is an edge connecting a Movie to an Award.两者都使用 VARIANT 列来实现灵活的属性。演员是一个节点。电影是一个节点。“表演”是连接它们的边。奖项是一个节点。“赢得”是连接电影和奖项的边。
This simplicity matters. When the business introduces a new entity type — a Screenwriter, a Composer, a Film Festival — there is no need to create a new table. You insert new nodes of that type. The schema remains stable while the graph grows organically.这种简单性非常重要。当业务引入新的实体类型——编剧、作曲家、电影节——时，无需创建新表。你只需插入该类型的新节点。模式保持稳定，而图谱则有机地增长。
Why Knowledge Graphs Matter for Data Platforms为什么知识图谱对数据平台很重要
Traditional relational queries answer questions about known, direct relationships: “Give me all movies by director X.” But business questions are often about indirect or emergent relationships:传统的关系查询回答的是关于已知、直接关系的问题：“给我导演 X 的所有电影。”但业务问题往往涉及间接或涌现的关系：
- “Which actors have worked with directors who also worked with Actor X?” (multi-hop traversal — the classic Six Degrees of Kevin Bacon problem)“哪些演员与也曾与演员 X 合作过的导演合作过？”（多跳遍历——经典的凯文·贝肯六度分隔问题）
- “What is the shortest path between Meryl Streep and Leonardo DiCaprio through shared movies?” (pathfinding)“梅丽尔·斯特里普和莱昂纳多·迪卡普里奥之间通过共同电影的最短路径是什么？”（路径查找）
- “Which persons in our database are connected to Movie M-2045?” — not just actors, but directors, producers, and any entity the ontology classifies as a Person linked through any path (polymorphic reasoning)“我们数据库中哪些人与电影 M-2045 相关联？”——不仅仅是演员，还包括导演、制片人以及本体论归类为“人”并通过任何路径链接的任何实体（多态推理）
- “Which genres cluster together through shared actor networks?” (community detection and influence analysis)“哪些类型通过共同的演员网络聚集在一起？”（社区检测和影响力分析）
These are graph problems. They require traversal and abstraction, not just joins. The “Six Degrees of Kevin Bacon” parlor game — where any actor can be connected to Kevin Bacon through a chain of shared movies in six hops or fewer — is literally a graph traversal problem. A knowledge graph makes it a simple query.这些都是图论问题。它们需要遍历和抽象，而不仅仅是连接。“凯文·贝肯六度分隔”游戏——即任何演员都可以通过一系列共同电影在六跳或更短的距离内与凯文·贝肯建立联系——本质上就是一个图遍历问题。知识图谱使这成为一个简单的查询。
Knowledge Graph on SnowflakeSnowflake 上的知识图谱
Snowflake provides all the primitives needed to build and query knowledge graphs at scale:Snowflake 提供了在大规模环境下构建和查询知识图谱所需的所有原语：
Two-Table Foundation — The node-edge model maps directly to Snowflake tables. VARIANT columns store heterogeneous properties without schema rigidity. An Actor node has different attributes than a Movie node, but both live in the same table.双表基础——节点-边模型直接映射到 Snowflake 表。VARIANT 列存储异构属性，无需模式僵化。演员节点具有与电影节点不同的属性，但两者都存在于同一个表中。
Recursive CTEs for Traversal — Snowflake supports WITH RECURSIVE, enabling multi-hop traversal, pathfinding, and connected component discovery. Walk a graph 3, 5, or N hops deep using standard SQL -- no external graph engine required. Find the shortest path between any two actors through shared movies.用于遍历的递归 CTE——Snowflake 支持 WITH RECURSIVE，支持多跳遍历、路径查找和连通分量发现。使用标准 SQL 即可在图谱中进行 3 跳、5 跳或 N 跳的深度遍历——无需外部图引擎。通过共同电影查找任意两位演员之间的最短路径。
Auto-Generated Views — A compiler (stored procedure) reads the ontology metadata and automatically generates views that unify entity subtypes. Query “all Persons” and get Actors, Directors, Producers, and any future subtypes — without writing or maintaining the SQL yourself. If a new subtype is added (Screenwriter), rerunning the compiler expands the view. Existing downstream queries continue to work.自动生成的视图——编译器（存储过程）读取本体论元数据，并自动生成统一实体子类型的视图。查询“所有人员”即可获取演员、导演、制片人以及未来添加的任何子类型——无需自己编写或维护 SQL。如果添加了新的子类型（例如“编剧”），重新运行编译器即可扩展该视图。现有的下游查询将继续正常工作。
UDFs for Agent-Consumable Reasoning — Graph traversal logic can be encapsulated in SQL or Snowpark UDFs, then exposed to Cortex Agents as callable tools. The knowledge graph becomes an active reasoning capability, not just a passive data store.用于智能体可消费推理的 UDF——图遍历逻辑可以封装在 SQL 或 Snowpark UDF 中，然后作为可调用工具暴露给 Cortex 智能体。知识图谱成为一种主动的推理能力，而不仅仅是被动的数据存储。
Tasks and Streams for Freshness — Knowledge graphs need to stay current. Snowflake Tasks and Streams detect changes in source tables and incrementally update nodes and edges, keeping the graph fresh without full rebuilds.用于保持新鲜度的任务和流——知识图谱需要保持最新。Snowflake 任务 (Tasks) 和流 (Streams) 可以检测源表中的变化并增量更新节点和边，无需完全重建即可保持图谱新鲜。
Knowledge Graph vs. Relational Joins知识图谱与关系连接
3. Semantic Layer — Translating Business to SQL3. 语义层——将业务翻译为 SQL
What Is a Semantic Layer?什么是语义层？
The semantic layer is the query-time abstraction that translates business concepts into executable SQL. It sits between the business user (or AI agent) and the physical data, providing:语义层是查询时的抽象，将业务概念转换为可执行的 SQL。它位于业务用户（或人工智能智能体）与物理数据之间，提供：
- Consistent metric definitions — Box Office Total always means SUM(DOMESTIC_GROSS + INTERNATIONAL_GROSS), everywhere一致的指标定义——“票房总额”在任何地方始终意味着 SUM(本土票房 + 国际票房)
- Relationship awareness — the system knows how to join Movies to Actors without being told关系意识——系统无需被告知就知道如何将电影连接到演员
- Dimensional context — what you can group by, filter on, or drill into维度上下文——你可以按什么进行分组、过滤或钻取
- Access control — which metrics are public vs. private访问控制——哪些指标是公开的，哪些是私有的
Where the ontology defines what is allowed to exist and the knowledge graph records what actually exists, the semantic layer encodes how to measure and analyze what exists.如果说本体论定义了允许存在什么，知识图谱记录了实际存在什么，那么语义层则编码了如何衡量和分析这些存在的事物。
Why Multiple Semantic Models, Not One为什么需要多个语义模型，而不是一个
An important design insight: avoid building a single massive semantic view over the entire ontology. Different questions require fundamentally different approaches.一个重要的设计洞察：避免在整个本体论之上构建一个单一的庞大语义视图。不同的问题需要根本不同的方法。
Asking “What is the total box office for Movie M-2045?” is a concrete, operational query — it needs speed and specificity. Asking “Which persons are connected to Director D-301 through shared movies?” is an abstract, polymorphic question — it needs the ontology to understand that Actors, Directors, and Producers are all Persons linked through various relationship paths. Asking “What entity types exist in the system?” is a governance question about the model itself.询问“电影 M-2045 的总票房是多少？”是一个具体的、操作性的查询——它需要速度和特异性。询问“哪些人通过共同电影与导演 D-301 相关联？”是一个抽象的、多态的问题——它需要本体论来理解演员、导演和制片人都是通过各种关系路径链接的“人”。询问“系统中存在哪些实体类型？”是一个关于模型本身的治理问题。
This leads to three purpose-built semantic models over the same underlying knowledge graph:这导致了在同一个底层知识图谱之上构建三个专门用途的语义模型：
Beneath them all lies the same source of truth, exposed through three optimized interfaces.在它们之下是同一个事实来源，通过三个优化的接口暴露出来。
Semantic Layer on SnowflakeSnowflake 上的语义层
Snowflake has made the semantic layer a first-class platform capability:Snowflake 已将语义层打造为一流的平台功能：
Semantic Views — Schema-level objects that define business semantics directly in the database. A semantic view maps physical tables to logical tables, then layers on dimensions, metrics, facts, relationships, and verified queries. Semantic views are governed by RBAC, shareable via Snowflake Marketplace, and queryable via both SQL and natural language.语义视图——直接在数据库中定义业务语义的模式级对象。语义视图将物理表映射到逻辑表，然后分层添加维度、指标、事实、关系和经过验证的查询。语义视图受 RBAC 治理，可通过 Snowflake Marketplace 共享，并可通过 SQL 和自然语言进行查询。
Key elements of a semantic view:语义视图的关键要素：
Cortex Agents — AI agents that consume semantic views as tools. When a user asks a natural language question, the agent reads the semantic view definition — metrics, dimensions, relationships, verified queries, instructions — and generates correct SQL against the physical tables. Structured business knowledge guiding probabilistic AI generation.Cortex 智能体——将语义视图作为工具使用的人工智能智能体。当用户提出自然语言问题时，智能体读取语义视图定义（指标、维度、关系、经过验证的查询、指令），并针对物理表生成正确的 SQL。结构化的业务知识引导概率性的人工智能生成。
Cortex Analyst — The engine behind natural-language-to-SQL. Reads semantic view YAML, uses verified queries for few-shot learning, applies custom instructions for business rules, and routes queries through Routing Mode for higher accuracy.Cortex Analyst——自然语言转 SQL 背后的引擎。读取语义视图 YAML，使用经过验证的查询进行少样本学习，应用自定义指令处理业务规则，并通过路由模式 (Routing Mode) 路由查询以提高准确性。
Sharing and Marketplace — Semantic views can be shared via listings or the Snowflake Marketplace. Business definitions travel with the data — consumers get the meaning layer, not just the tables.共享与市场——语义视图可以通过列表或 Snowflake Marketplace 进行共享。业务定义随数据一起流动——消费者获得的是含义层，而不仅仅是表。
Semantic Layer vs. Views and BI Tools语义层与视图及 BI 工具
The Five-Layer Architecture五层架构
When composed on Snowflake - ontology, knowledge graph, and semantic layer form a five-layer stack. The key takeaway: facts are stored once, meanings are defined as configuration, and intelligence is orchestrated dynamically.当在 Snowflake 上组合时，本体论、知识图谱和语义层形成了一个五层架构。关键要点：事实只存储一次，含义作为配置定义，智能则动态编排。
How It Flows运作流程
It is the foundation. Two tables. Every entity in your business is a node; every connection is an edge.这是基础。两张表。你业务中的每个实体都是一个节点；每个连接都是一条边。
It introduces meaning. Business logic is defined declaratively in metadata tables, not embedded in SQL code. The model evolves with business through metadata inserts/updates, not schema rewrites.它引入了含义。业务逻辑以声明式方式定义在元数据表中，而不是嵌入在 SQL 代码中。模型通过元数据插入/更新随业务演进，而不是通过模式重写。
It is generated automatically. A compiler stored procedure reads the metadata and produces views that unify entity subtypes. No one writes or maintains these views by hand. Add a new subtype of Person (say, Screenwriter), rerun the compiler, and the unified Person view expands automatically. Existing downstream queries continue to work.它是自动生成的。编译器存储过程读取元数据并生成统一实体子类型的视图。没有人手动编写或维护这些视图。添加一个新的“人”的子类型（例如“编剧”），重新运行编译器，统一的“人”视图就会自动扩展。现有的下游查询将继续正常工作。
It contains three purpose-built semantic models — knowledge graph, ontology, and governance — each optimized for different question types, all over the same underlying data.它包含三个专门用途的语义模型——知识图谱、本体论和治理——每个都针对不同类型的问题进行了优化，所有这些都基于同一个底层数据。
It is the Cortex Agent. It acts like a conductor leading an orchestra. Each tool is specialized, and the agent determines which tool should answer a given question. A concrete question like “What is the average rating by genre?” routes to the KG model. An abstract question like “Which persons are connected to Director D-301?” routes to the ontology model. A governance question like “What entity types exist?” routes to the governance tools. Multiple tools can be called in parallel, and results are combined into a single coherent answer.它是 Cortex 智能体。它就像指挥管弦乐队的指挥家。每个工具都是专业的，智能体决定哪个工具应该回答给定的问题。像“按类型的平均评级是多少？”这样的具体问题会路由到 KG 模型。像“哪些人与导演 D-301 相关联？”这样的抽象问题会路由到本体论模型。像“存在哪些实体类型？”这样的治理问题会路由到治理工具。多个工具可以并行调用，结果被合并为一个连贯的答案。
This is intelligence through orchestration, not reliance on a single model.这是通过编排实现的智能，而不是依赖单一模型。
Which Layer Answers Which Question?哪一层回答哪个问题？
Why This Matters Now为什么现在这很重要
AI Agents need structured knowledge. Cortex Agents and LLM-powered applications are moving from demos to daily use. An agent that can query an ontology, traverse a knowledge graph, and read a semantic view is fundamentally more capable than one that only sees raw table schemas. The difference is the difference between an intern with a data dictionary and a domain expert with 20 years of experience.人工智能智能体需要结构化知识。Cortex 智能体和基于大语言模型的应用程序正在从演示走向日常使用。一个能够查询本体论、遍历知识图谱并读取语义视图的智能体，从根本上比一个只能看到原始表模式的智能体更有能力。这种差异就像是一个拿着数据字典的实习生与一位拥有 20 年经验的领域专家之间的区别。
Graph problems are everywhere in entertainment. Recommendation engines, content discovery, talent networks, franchise mapping, and audience segmentation are all fundamentally graph problems. The “Six Degrees of Kevin Bacon” parlor game — where any actor can be connected to Kevin Bacon through shared movies — is literally a graph traversal. Platforms that model these connections as knowledge graphs gain a structural advantage over those running disconnected point queries.图论问题在娱乐行业无处不在。推荐引擎、内容发现、人才网络、特许经营映射和受众细分本质上都是图论问题。“凯文·贝肯六度分隔”游戏——即任何演员都可以通过共同电影与凯文·贝肯建立联系——本质上就是图遍历。将这些联系建模为知识图谱的平台，相对于那些运行断开的点查询的平台，具有结构性优势。
Self-service is the expectation. Business users — from studio analysts to entertainment journalists — expect to ask questions in natural language and get trustworthy answers. The semantic layer makes that possible. The knowledge graph makes the answers richer. The ontology makes them consistent.自助服务是期望。业务用户——从制片厂分析师到娱乐记者——期望用自然语言提问并获得可信的答案。语义层使这成为可能。知识图谱使答案更丰富。本体论使它们保持一致。
Automation makes it practical. Five layers, three semantic models, a compiler, and an agent sound like significant work. But the process can be automated. The Ontology Stack Builder — a CoCo (Cortex Code) skill — guides you through the entire stack using an interactive, gated workflow. You provide your tables and business questions. The tool examines your schema, proposes an ontology, launches a visual graph editor for review, and then generates all SQL, deploys the layers, creates semantic views, provisions the Cortex Agent, and validates the solution end-to-end. What previously took weeks of handwritten SQL and manual agent setup can be completed in a single session.自动化使其实用化。五层架构、三个语义模型、一个编译器和一个智能体听起来工作量很大。但这个过程可以自动化。本体论架构构建器 (Ontology Stack Builder)——一种 CoCo (Cortex Code) 技能——通过交互式、门控的工作流引导你完成整个架构。你提供你的表和业务问题。该工具检查你的模式，提议一个本体论，启动一个可视化图谱编辑器供审查，然后生成所有 SQL，部署各层，创建语义视图，配置 Cortex 智能体，并端到端地验证解决方案。以前需要数周手动编写 SQL 和配置智能体的工作，现在可以在单次会话中完成。
If you’re building ontology-driven architectures or knowledge graphs on Snowflake, I’d love to hear about your approach. Drop a comment or connect.如果你正在 Snowflake 上构建本体论驱动的架构或知识图谱，我很乐意了解你的方法。欢迎发表评论或建立联系。
References:参考文献：
https://medium.com/snowflake/ontology-on-snowflake-from-architecture-to-deployment-with-a-cortex-code-skill-197866ce9c9fhttps://medium.com/snowflake/ontology-on-snowflake-from-architecture-to-deployment-with-a-cortex-code-skill-197866ce9c9f
https://www.youtube.com/watch?v=Ooan6cErKCMhttps://www.youtube.com/watch?v=Ooan6cErKCM
AI Disclosure: Selected images and visual representations were created using AI image generation models (LLMs and generative AI tools) to enhance the explanation. All technical content has been reviewed and validated by the author.AI 披露：部分图片和视觉呈现是使用 AI 图像生成模型（大语言模型和生成式 AI 工具）创建的，旨在增强说明效果。所有技术内容均已由作者审核并验证。
