同名異物：W3C 說 ontology 歷史複雜，Cube 把資料模型叫 knowledge graph

W3C 的 OWL 2 入門文件（Primer）在說明 OWL 2 是一種表達 ontology 的語言之後，緊接著寫了這句：“The term ontology has a complex history both in and out of computer science, but we use it to mean a certain kind of computational artifact”（W3C OWL 2 Primer，2026 年 9 月查閱）。定義這個詞的文件先承認詞義有歷史包袱，再交代自己取的是哪一種意思。

拿這句話當提醒，再去翻其他文件，同一個詞的用法就不再整齊：Cube 的文件把資料模型稱作 knowledge graph，同一頁又說自己建在開源的 semantic layer 上，Microsoft Fabric IQ 的 ontology 專頁自稱是 semantic modeling layer，Palantir 的文件則寫明 Ontology 不是 semantic layer，理由是 thin semantic layer 做不到四項整合，同一份文件卻也用 semantic 這個字描述自己的語言。

同一個字，不同的東西。

本文先承認名稱不足以單獨判別，改問四個問題：文件叫你定義的基本單位是什麼，消費端拿定義去做什麼，有沒有形式推論，動作住在哪裡，而權限掛在哪一層是第五個附帶的問題。「四題」與後面出現的「三頭」，都是本文的整理，不是任何一家或任何標準的官方分類。

比對只看官方文件自己怎麼寫，事實時點是 2026 年 9 月查閱，頁面之後會變；文件沒寫的地方，本文寫「頁面沒寫」，那不等於做不到，而讀者要拿走的是一個判斷動作：別人說 ontology 的時候，該問什麼。本文接續系列第一篇、第二篇與第三篇，第三篇結尾預告的正是這一題：dbt、Cube、LookML、知識圖譜與 Palantir 各自叫 ontology 或 semantic layer 的，到底是什麼。

Cube 把資料模型叫 knowledge graph，Fabric IQ 把 ontology 叫 semantic modeling layer

Cube 的 intro 頁寫著：“The data model is the knowledge graph the platform — and any AI agent — uses to understand your business.”（Cube 官方文件，2026 年 9 月查閱，intro 頁）這是官方自己的說法，同一頁又把 Cube 描述成建在開源 semantic layer 上的平台，所以兩個詞在同一頁並存。這個詞在 Cube 文件裡出現得不多：本文讀的 Cube 三頁裡，knowledge graph 只出現在 intro 頁一次，資料模型頁與 access policies 頁是 0 次。

dbt 走的是另一個字，semantic models 頁寫：“Think of semantic models as nodes connected by entities in a semantic graph.”（dbt 官方文件，2026 年 9 月查閱，semantic models 頁）這裡用的是 semantic graph，不是 ontology，也不是 knowledge graph。

Fabric IQ 專頁的用法最接近本文開頭的疑問，專頁先寫：“Ontology is the business context and semantic modeling layer between enterprise data and the experiences that consume it.”，同一段接著說它 “isn’t itself a general-purpose data-query engine”，另一處又寫 “Ontology acts as a virtual semantic and context layer over these sources.”（Microsoft 官方文件，2026 年 9 月查閱，Fabric IQ ontology 頁）。專頁兩處把 ontology 稱為 layer，並說它不是查詢引擎。

專頁也寫了它與 semantic model 的關係：“You can build an ontology from scratch, or you can generate it directly from semantic models.”（同頁）這份文件裡的 ontology 可以是從 semantic model 長出來的東西，而專頁在 2026 年 9 月查閱時標的是 preview，所以本文提到的 Fabric IQ ontology，一律指這個 preview 狀態的頁面。

ServiceNow Community 網站上有一篇 2025 年 11 月 17 日發佈的文章，快照看不出作者是不是官方帳號，而同一篇並用了三個詞：文章寫 “Knowledge Graph is a semantic overlay that helps AI understand how your business works.”，又把定義 Knowledge Graph 得到的這個結構稱為 ontology，小標題卻是 “How the Semantic Layer Works”。同篇另外寫這個 Knowledge Graph 不儲存新資料，也不推論關係。C3 AI 官網的行銷頁把整個企業建模成一張 ontology graph，那是行銷頁的措辭，不是技術文件。

本文讀的 dbt 6 頁、Cube 3 頁、Looker 8 頁、Databricks 1 頁、Snowflake 2 頁與 Microsoft semantic models 頁，ontology 這個詞出現 0 次；Fabric IQ 與 Palantir 的頁面則通篇使用這個詞，下表把這幾處自稱並排，表中是轉述，逐字引句見正文。

Palantir 寫 Ontology 不是 “semantic layer”，理由是 thin semantic layer 做不到四項整合，同一份文件也用 semantic 這個字

Palantir 的 arch-ontology-system 頁寫：“The Ontology is not a ‘semantic layer’; the fourfold integration and operationalization of data, logic, action, and security cannot be accomplished with a thin semantic layer or a monolithic design.”（Palantir 官方文件，2026 年 9 月查閱，arch-ontology-system 頁）否定的對象是 thin semantic layer，理由是四項整合做不到，這句話比「Ontology 不是 semantic layer」長，也比它窄。

同一頁稍後就用了這個字：“The Language models the semantic objects, links, and properties; along with the kinetic actions and automations”，另一處寫 “semantics must be paired with kinetics”（同頁），可見 semantic 是 Palantir 描述自己的詞，而 kinetic 是它的另一半。why-ontology 頁也寫：“Uniting data within a semantic model and combining it with the logic required to evaluate decisions is valuable, but ultimately limited unless the executed decisions can be synchronized with operational systems in a way that compounds, with each decision informing the next in a shared lineage.”（Palantir 官方文件，2026 年 9 月查閱，why-ontology 頁）受限的是只停在這裡、而不能與營運系統同步，semantic model 本身仍被說成有價值。另外，overview 頁把 Ontology 稱為 operational layer，並寫在許多情境下它充當組織的 digital twin。

Palantir 對自己的定義寫在 core 頁，core 頁寫：“An Ontology is a categorization of the world.”，並說明它是把資料集與模型對應到 object types、properties、link types 與 action types；同頁又拿資料集類比：“You can think of each object type as analogous to a dataset”（Palantir 官方文件，2026 年 9 月查閱，core 頁）。overview 頁則把自己與資料目錄、schema 設計工具區隔開來：“Far beyond data cataloging or schema design solutions, the Ontology allows you to define a robust foundation for end-user workflows”（Palantir 官方文件，2026 年 9 月查閱，ontology-overview 頁）。

名稱不足以單獨判別，本文改問四個問題

把前面幾處放在一起，能寫的結論很窄：Cube 的資料模型叫 knowledge graph，Fabric IQ 的 ontology 自稱 semantic modeling layer 又能從 semantic model 生成，Palantir 否定 thin semantic layer 又用 semantic 這個字，ServiceNow Community 的一篇文章同時用了三個詞，所以這幾份文件顯示名稱不足以單獨判別。

改問什麼？第一題問文件叫你定義的基本單位是什麼：class、指標、實體，還是 object type；第二題問消費端拿定義去做什麼：推導、編譯查詢，還是讀寫物件；第三題問文件有沒有寫形式推論；第四題問動作住在哪裡，是定義裡的一等型別，還是別處的參數、另一條線，或文件沒寫，而權限掛在哪一層是附帶的第五問。

第四題的問法要精確，因為它不問「有沒有 action」（Looker 有欄位上的 action 參數，dbt 有 exports），而是問動作是不是定義裡的一等型別，這讓 Looker、dbt、Palantir 可以各就各位，不必先爭論誰「有」動作。

四題把本文讀的文件分成三頭：第一頭是 W3C，單位是詞彙加 reasoner；第二頭是 Palantir，單位是 object、link、action type 加 function；第三頭是 semantic layer 家族，單位是指標、維度、實體加查詢，而 Fabric IQ 的 ontology 落在第三頭旁邊，後面用它的專頁逐格交代，並標出專頁裡第三頭沒寫的東西。

W3C 的 ontology 是有形式語意的詞彙，由 reasoner 推導，OWL 2 自己說不是資料庫

OWL 2 Overview 頁寫：“Ontologies are formalized vocabularies of terms, often covering a specific domain and shared by a community of users.”（W3C OWL 2 Overview，2026 年 9 月查閱）Overview 與 Primer 合看，基本單位是 class、property、individual，Primer 稱其中的陳述為 axiom。消費端拿詞彙做什麼，Primer 說得很具體：“Appropriate tools (so-called reasoners) can then be used to infer further information about that state of affairs.”（W3C OWL 2 Primer，2026 年 9 月查閱）Overview 頁提到兩套語意，並寫 “These two semantics are used by reasoners and other tools”（W3C OWL 2 Overview，2026 年 9 月查閱）。

所以第三題的答案在這一頭是有，而且是核心。

Primer 同時劃了幾條線，避免讀者把 OWL 當成別的東西，第一條是資料庫：“OWL 2 is not a database framework.”，理由是資料庫預設缺一個事實就當作假，“it is usually considered false (the so-called closed-world assumption)“，OWL 文件則依 “following the open-world assumption”，缺的事實可能只是沒寫出來（以上 W3C OWL 2 Primer，2026 年 9 月查閱）。第二條是 schema 與名字，Primer 寫 OWL 2 不是檢查語法的 schema 語言：“there is no way to enforce that a certain piece of information (like the social security number of a person) has to be syntactically present.”，原意是 OWL 不強制某項資料必須出現，而名字也不同於資料庫欄位值：“OWL does not make the assumption that different names are names for different individuals.”（同頁）兩個名字可能指同一個個體。

資料形狀的驗證是另一個標準 SHACL，SHACL 頁寫它是 “a language for validating RDF graphs against a set of conditions”，但用途不只驗證：“Such descriptions may be used for a variety of purposes beside validation, including user interface building, code generation and data integration.”（W3C SHACL，2026 年 9 月查閱）兩者還可以接：SHACL 頁寫 “SHACL implementations MAY, but are not required to, support entailment regimes.”，並提供 “sh:entailment to indicate what inferencing is required by a given shapes graph.”（同頁）Primer 對長得像 schema 的語句也有提醒：“note that a domain (or range) statement is not a constraint on the knowledge, but allows a reasoner to infer further knowledge”（W3C OWL 2 Primer，2026 年 9 月查閱）。本文把這兩處接起來的整理是：同樣長得像 schema 的語句，在 OWL 裡是推論，在 SHACL 裡是約束，這個接法是本文的，不是 Primer 的話。

第四題呢？本文讀到的 W3C 頁面，範圍描述圍繞詞彙、圖資料與驗證，而 SHACL、RDF 與 OWL 2 Overview 本文只讀了其中一部分，所以這一格只寫這些頁面沒寫。

dbt、Cube、LookML 用指標、維度與實體定義模型，消費端拿定義編譯並限制查詢

dbt 的 Semantic Layer 頁自述是用來定義並使用關鍵 business metrics，這一句第一篇已經引過，所以這裡改看它怎麼描述單位，MetricFlow 頁寫：“Entities: The join keys of your semantic model (think of these as the traversal paths, or edges between semantic models).”（dbt 官方文件，2026 年 9 月查閱，MetricFlow 頁）也就是說 entity 是連接 semantic model 的 join key。

dbt 文件的單位要逐頁標版本，semantic models 頁的區塊標著 “Applies to dbt v1.12 and later”，該頁的範例 YAML 已改用 simple metrics（註解寫 Simple metrics replace measures）（dbt 官方文件，2026 年 9 月查閱，semantic models 頁）。所以該頁的單位是 semantic model（含 entities、dimensions、simple metrics）加 metrics。消費端怎麼用這些定義？MetricFlow 頁寫：“When MetricFlow generates a metric, it uses its SQL engine to figure out the best path between tables using the framework defined in YAML files for semantic models and metrics.”（dbt 官方文件，2026 年 9 月查閱，MetricFlow 頁）定義被用來規劃 SQL，而對外的介面寫在 APIs 頁：“Use GraphQL to query metrics and dimensions in downstream tools.”，以及 “Use a JDBC driver to query metrics and dimensions in downstream tools, while also providing standard metadata functionality.”（dbt 官方文件，2026 年 9 月查閱，Semantic Layer APIs 頁）

Cube 的單位是 cubes 與 views，intro 頁寫：“Cubes represent business entities — customers, orders, line items.”，接著 “They define measures, dimensions, and joins between entities.”（Cube 官方文件，2026 年 9 月查閱，intro 頁）Cube 也給自己下了分類：“Cube’s model is dataset-centric, expanding on dimensional modeling.”（同頁）Cube 對消費端寫得特別清楚：“Every query passes through the semantic layer runtime, where it’s validated against the data model and has access policies applied deterministically before reaching the warehouse.”（同頁）定義是查詢路徑上的一道關卡，先驗證、再套用政策、才到 warehouse，而權限也掛在這一層：“Access control runs at the semantic layer, so the same policies apply to every consumer: AI agents, BI tools, embedded applications.”（同頁）政策寫在資料模型裡：“Declares group-scoped policies that combine member access, row filters, and masking rules directly in the data model.”（Cube 官方文件，2026 年 9 月查閱，access policies 頁）這些政策以 group 為目標，掛在 cube 或 view 上都可以，更常見的是掛在 view。

LookML 頁自稱這是 Looker 用來建立 semantic data models 的語言，元件是 dimensions、aggregates、calculations 與資料關係，由 Looker 的 SQL generator 把 LookML 譯成 SQL。權限方面，access_grant 在 model 檔裡定義，可以要求於 Explore、join、view 與 field；另有 access_filter 掛在 Explore 層，做列級篩選。

Databricks 與 Microsoft 本文各只讀一頁（入口或章節性質），Snowflake 讀了兩頁（semantic views 概述頁與 OSI blog）。Databricks 的 metric views 頁把 measure 與維度欄位分開定義；Snowflake 的 semantic view 是 schema 層級的物件，文件說它算 metadata；Microsoft 那頁是 Fabric warehouse 章節，把 Power BI semantic model 說成對分析領域的邏輯描述。這三家的權限與動作格子，本文讀到的頁面沒寫。

Snowflake 頁也寫了 AI 的用法：“You can use Semantic Views in Cortex Agents and query these views in a SELECT statement.”，以及 “Semantic views improve accuracy by combining LLM reasoning with rule-based definitions.”（Snowflake 官方文件，2026 年 9 月查閱）這裡的 reasoning 指的是 LLM 推理，本文的判讀是它不是 W3C 意義的形式推論。

到這裡可以整理消費端：Cube、Snowflake、Fabric IQ 的 overview 頁與 Palantir 都列了 AI agent 當消費者，所以「消費端是不是 agent」分不出差別。本文的讀法是差別在消費端拿定義去做什麼：dbt 與 Cube 拿定義編譯並限制查詢，W3C 的 reasoner 依公理推導，Palantir 的應用程式與 agent 讀寫物件並叫用 action。這是本文的讀法，不是任何一家自己下的分類；若某家文件把消費端另寫成別的用法，這個讀法就要改。

三個會被讀者反駁的地方：Looker 的 action、dbt 的 exports、Cube 的 knowledge graph

讀到這裡，有人會反駁：semantic layer 不是只讀的嗎，Looker 不是有 action，dbt 不是能寫表，Cube 不是自己叫 knowledge graph？三個反駁都有文件撐腰，所以分開交代，三者也不同類。

先看 Looker 的 action 參數，param-action 頁寫：“The action parameter creates a data action that lets users perform field-level tasks in other tools, directly from Looker.”（Looker 官方文件，2026 年 9 月查閱，param-action 頁）動作掛在欄位上：“You can define an action for a dimension or measure.”，接收端的條件是：“The receiving server must be able to accept a JSON POST.”（同頁）成敗怎麼判定，文件也寫了：“A successful HTTP response will be considered a successful action.”（同頁）接收端可以對表單參數回傳 validation errors；沒有表單的 data action，則在 Actions 選單左側顯示載入、勾號與失敗的圖示狀態。所以 Looker data action 的定義寫的是送出去的請求：label、url、param、form，由接收端伺服器執行。

Looker 還有另一條線，action hub 頁寫：“Actions that are served through an action hub server differ from data actions, which are defined by the action LookML parameter.”（Looker 官方文件，2026 年 9 月查閱，action hub 頁）

兩條線是文件自己分開的。

寫回資料倉儲的頁面要小心讀。Looker 官方 best-practices 頁寫：“This documentation page walks customers who use Google Cloud infrastructure through deploying a solution on Cloud Run functions to write back to BigQuery.”（Looker 官方文件，2026 年 9 月查閱，BigQuery 寫回頁）頁面同時寫 “Through its Action API, Looker supports this use case for any data warehouse or destination.”，並教客戶把官方附的 demo 程式（頁面寫 our demo action’s logic）部署到 Cloud Run functions。寫入由客戶部署的服務執行，不是 Looker 本體內建的功能。

同一頁說明這個解法只 append 資料列，現況可在查詢時從 log 推導：“you can always derive ‘current state’ tables at query time from an append-only log, thus simulating updates.”（同頁）而 append-only 是這個 demo 的設計，不是 Looker 的規則。

Looker 端有沒有 transaction、rollback、idempotency 或稽核的敘述，本文檢視的 data action、action hub 與寫回頁沒找到，也沒抓到專門的 audit-log 頁，查不到不等於沒有；action hub 頁測試段落有一句提到歷史紀錄：測試的狀態會出現在 Admin 面板的 Scheduler History。

第二個是 dbt 的 exports。exports 頁寫：“Exports enhance saved queries by running your saved queries and writing the output to a table or view within your data platform.”（dbt 官方文件，2026 年 9 月查閱，exports 頁）並說明它 “directly executes a ‘create table’ statement so the data stays within your data platform.”。同頁還寫：“No, you won’t be able to reference an export using ref. Exports are treated as leaf nodes in your DAG.”，是葉節點，不會被別的 model 用 ref 接回去。exports 頁的先決條件寫 dbt 1.7 以上。dbt exports 寫進的是同一個資料平台，Looker action 送請求給接收端，兩者不同類。至於 dbt 對外部系統的動作，GraphQL、JDBC、Python SDK 的子頁與權限細節頁沒有快照，本文讀到的頁面沒寫。

第三個是 Cube 自稱 knowledge graph，前面已經逐字引過，所以這裡只補範圍：這個詞在本文讀的三頁裡只在 intro 頁出現一次，指的是資料模型。

三個反駁合起來說明一件事：semantic layer 家族的定義句，重心在指標、維度、實體與查詢；動作在別處出現，形式各異，Looker 是欄位上的參數，dbt 是寫進同一平台的表。

Palantir 文件叫你定義 object type、link type、action type 與 function

core 頁對三種單位各給了一句定義：“An object type defines an entity or event in an organization.”，“A link type defines the relationship between two object types.”，“An action type defines how an object type can be modified.”（Palantir 官方文件，2026 年 9 月查閱，core 頁）action type 與 object type、link type 並排，是定義裡的一等型別，這與前面三個反例的結構不同。

Palantir 也把 function 與動作連在一起，overview 頁把 Ontology 描述成同時含 semantic 元素（objects、properties、links）與 kinetic 元素（actions、functions、dynamic security）。action-overview 頁寫 action type “also includes the side effect behaviors that occur with action submission.”（Palantir 官方文件，2026 年 9 月查閱，action-overview 頁）動作、規則與副作用被寫在同一個定義裡，第二篇已經拆過，所以這裡不再重寫，而副作用的範圍，官方也寫了：“This enables you to write to other source systems in your organization”（Palantir 官方文件，2026 年 9 月查閱，action side effects 頁）。

外部系統的交易性，webhooks 頁分兩型寫。writeback 型：外部請求失敗，Ontology 就不套用任何變更；但外部請求成功而 Ontology 變更失敗仍有可能，文件形容這是某種程度的 transactionality。side effect 型：在物件變更之後執行，webhooks 頁的表格寫失敗不會顯示給終端使用者（Failure shown to end user? 一欄，writeback 列 Yes、side effect 列 No），文件寫 “You should use side effect webhooks when you want to send best-effort notifications or write back to multiple external systems.”（Palantir 官方文件，2026 年 9 月查閱，action webhooks 頁）

拿它跟 Looker 對照，本文的整理是：Looker data action 的定義寫的是送出去的請求，Palantir action type 的定義寫的是對 Ontology 物件、屬性、連結的變更，並可附通知或 webhook。這是文件結構的比較，也是揭露程度的差異，不是能力優劣：Palantir 自己寫了交易性的限制，Looker 文件則沒討論這一題，兩邊都不等於已證實的端到端交易保證。若 Looker 另有文件寫了 transaction 語意，這個比較就要改。

消費端這一題，Palantir 的答案是應用程式、SDK 與 agent。OSDK 頁寫：“The Ontology Software Development Kit (OSDK) allows you to access the full power of the Ontology directly from your development environment.”（Palantir 官方文件，2026 年 9 月查閱，OSDK overview 頁）why-ontology 頁則寫：“the decision-centric Ontology connects humans and agents directly to operations”（why-ontology 頁）。本文的讀法是人與 agent 讀寫物件並叫用 action。

權限這一格，兩頁各自描述自己的對象。permissions 頁寫：“This capability is enabled for new ontologies. For existing ontologies, an ontology owner must enable the capability manually, and existing ontology resources require migration. This capability is not yet available for Default Ontologies.”，並說 “This project-based permissions approach replaces the previous permission models: ontology roles and datasource-derived permissions.”（Palantir 官方文件，2026 年 9 月查閱，permissions 頁）core 頁則仍寫：“Roles are the central permissioning model in the Ontology.”（core 頁）新的 ontology 用專案式權限，既有的要手動啟用，core 頁仍寫 Roles，而 permissions 頁寫了 new、existing、Default Ontologies 的啟用狀況，沒寫已遷移的比例。

Palantir 的十頁正文未出現 OWL 或 RDF，匯出入寫的是自家 JSON

Palantir 這一頭在第三題上的答案，要從字串說起：本文讀的十頁（why、overview、core、arch、object、action、webhooks、side-effects、permissions、OSDK）正文都沒有出現 OWL、RDF、SPARQL、triple、knowledge graph、inference、entailment、reasoner、SHACL 這些詞。reasoning 有出現，語境是決策邏輯或 LLM 推理，why-ontology 頁的一句是 “the non-deterministic reasoning of LLMs”（Palantir 官方文件，2026 年 9 月查閱，why-ontology 頁）；arch 頁另有 decision graph 這個詞，指的也是決策。

互通頁寫的是另一件事：“All elements in an organization’s Ontology can be accessed through REST APIs and configured through JSON-driven authoring paradigms. This allows for bidirectional synchronization with existing semantic modeling tools, ontologies resident within data catalogs, and domain-specific modeling tools.”（Palantir 官方文件，2026 年 9 月查閱，interoperability 頁）文件只說 REST 與 JSON 使雙向同步成為可能，格式、保真度與機制頁面沒寫。匯出入頁寫：“Ontology schema definitions are stored in a JSON file”，同時提醒 “You should not depend on the exported JSON schema as it may change over time.”（Palantir 官方文件，2026 年 9 月查閱，ontology export／import 頁）匯出入的是自家 JSON，而且文件提醒不要依賴那份 schema 的穩定。

Fabric IQ 的 ontology（preview）從 semantic model 生成，單位是 entity type 與自然語言 rule

Fabric IQ 專頁的定義寫：“The ontology (preview) item in Microsoft Fabric IQ provides a shared, machine-understandable representation of your business.”，並寫 “This feature is in preview.”（Microsoft 官方文件，2026 年 9 月查閱，Fabric IQ ontology 頁）以下對這份專頁的敘述，都以 preview 為前提。專頁的單位有 entity type、property、relationship、metric、rule：“An entity type is the reusable definition of a business concept, such as Customer, Shipment, Machine, or Store.”，“A metric represents a governed calculation associated with ontology concepts.”，以及 “A rule is a natural-language statement of business logic linked to ontology concepts.”（同頁）它與 semantic model 的關係，文件寫得直接：“Ontology aligns with familiar semantic-model constructs while extending them with ontology-specific modeling concepts.”（同頁）單位裡有 metric，來源可以是 semantic model，這是本文把它放在 semantic layer 家族旁邊的依據，而「延伸」的部分，正是專頁不同於那一頭的地方。

第一個不同是 rule 寫成自然語言，專頁沒有 inference、reasoner、entailment 這些字樣，而第二個不同是可以匯入 W3C 格式：“Ontology can also import supported RDF, Turtle, and OWL definitions into an empty ontology item and export supported ontology definitions in RDF or Turtle formats.”（同頁）第三個不同是 graph 是選配的執行層：“Graph in Microsoft Fabric is an optional execution layer for scenarios in which the relationship path itself is important”，而且 “An ontology-derived schema graph doesn’t load instance data by default.”（同頁）專頁的核心概念清單另有 namespace 與 data binding。

把這一段與上一節並列：Fabric IQ 的文件明載可匯入 RDF、Turtle、OWL，匯出 RDF、Turtle；Palantir 的匯出入文件寫的是自家 JSON，並提醒不要依賴其 schema。這是兩份文件各自寫了什麼的並列，不是能力比較。

權限這一格，專頁寫：“Fabric workspace and item permissions control access to ontology items.”（同頁）同一句的後半說明綁定資料的存取沿用來源端的安全機制，包括 OneLake security 與 RLS、OLS、CLS，所以是兩層：workspace 與 item 權限，加上來源資料自己的權限。

動作這一格要指明主詞與頁面，因為三處文字的主詞與範圍不同，而規則頁的主詞是規則：“A business rule is a natural-language definition. Ontology doesn’t run the rule against data or execute actions.”（Microsoft 官方文件，2026 年 9 月查閱，rules 頁）同一頁把規則工具說成唯讀，並說新的 ontology 體驗目前沒有與 Activator 的直接整合。

overview 頁的主詞是 agents：“Ontology grounds agents in shared business language and rules so they can reason across domains and trigger governed actions.”（Microsoft 官方文件，2026 年 9 月查閱，Fabric IQ overview 頁）trigger 的是 agents，而 Build 發表文（2026 年 6 月 2 日，標題 Microsoft Build 2026）的主詞是 ontologies：“They define business entities, relationships, properties, rules, and actions, and connect to live signals from Fabric Real-Time Intelligence.”（Microsoft 官方 blog，2026 年 6 月 2 日）發表文把 actions 列進 ontology 的定義裡；actions 指什麼、由誰執行、如何授權，這份文章沒寫。專頁的 Core concepts 清單則只列 entity type、instance、property、relationship、metric、rule、namespace 與 data binding，沒有 action。

Fabric IQ、dbt 與 Snowflake 的文件顯示，本文所比的概念邊界有交會處

上面幾節看起來像三頭各有陣地，但幾份文件顯示邊界沒有那麼乾淨。Fabric IQ 的 ontology 可以從 semantic model 生成，也能匯入 OWL；dbt 的 MetricFlow 頁寫：“MetricFlow is developed and maintained by dbt Labs and works with the Apache Ossie format.”（dbt 官方文件，2026 年 9 月查閱，MetricFlow 頁）頁面沒說明 Ossie 是什麼，semantic models 頁則把它說成 dbt 原生 YAML 的替代。

Snowflake 的官方 blog 談的是交換標準。2025 年 9 月 23 日的文章寫：“The OSI initiative is a collaborative, open-source effort dedicated to standardizing and streamlining semantic model exchange and utilization”（Snowflake 官方 blog，2025 年 9 月 23 日），結尾寫 “Stay tuned for more updates as the OSI takes shape!”。發文當日的夥伴名單列了 Cube、dbt Labs、Salesforce、ThoughtSpot 等，但這是 2025 年 9 月的倡議，不是 2026 年 9 月的現況，而 Ossie 與 OSI 兩個名字出現在兩份不同的文件裡，快照沒有把它們連起來。

本文的整理是：Fabric IQ 從 semantic model 生成並可匯入 OWL，dbt 頁提到 Ossie，Snowflake blog 談交換標準，這三份文件顯示本文所比較的概念邊界並非彼此隔絕。樣本只有這幾家；若後續文件顯示交換的對象與格式另有主張，這個整理就要改。

四個問題加一個權限問題，把六種文件分成三頭

把前面各節的格子放進一張表，列是六種文件，欄是四題加權限，而空格＝頁面沒寫，不等於做不到。

先看第一欄，OWL 2 的單位是詞彙與公理，Palantir 的單位是四種型別，其餘四列的單位是指標、維度、實體或它們的近親，第一欄本身就把文件分開了一半，而第二欄與第三欄把 W3C 分出來：這一頭的消費端做的是推導，形式推論是核心，另外五列在第三欄不是「頁面沒寫」就是有限定。

第四欄把 Palantir 分出來，因為 Palantir 的動作是定義裡的型別；Looker 的動作是欄位上的參數，執行在接收端；dbt 的動作是寫進同一平台的表；Fabric IQ 規則頁寫 ontology 不執行，而這一欄不問有沒有，只問動作是不是定義裡的一等型別。

於是三頭是這樣分的：W3C 是詞彙加 reasoner，Palantir 是 object、link、action type 加 function，semantic layer 家族是指標、維度、實體加查詢。Fabric IQ 的 ontology 在四題上落在第三頭旁邊，同時專頁另有自然語言 rule、RDF 與 OWL 匯入、選配的 graph 層與 namespace，這些是第三頭頁面沒寫的東西。這是本文依上表整理的讀法；若 Fabric IQ 的文件另有把 action 或推論寫成一等型別，這個讀法就要改。

遇到別人說 ontology，先問他手上那份文件怎麼回答四題：他說的是詞彙與推導，靠近第一頭；他說的是物件、連結與動作型別，靠近第二頭；他說的是指標、維度與查詢，靠近第三頭。

答不出來的格子，就回去看文件，而不是靠名字猜。

這篇比的是 2026 年 9 月的文件，沒讀到的頁面不是答案

本文的頁面抓於 2026 年 9 月 29 日，之後會變，而頁面沒寫不等於做不到。Palantir 的結論限於十頁正文；Fabric IQ 的說法限於 preview 狀態的專頁、規則頁、overview 頁與 2026 年 6 月 2 日的發表文；Snowflake 的 blog 是 2025 年 9 月 23 日的歷史文章，OSI 之後有沒有成果、名單有沒有變，這批頁面答不出來。

dbt 的 GraphQL、JDBC、Python SDK 與權限子頁，Cube 導覽列的 Scheduled Tasks、Notifications、Agent skills 頁，Databricks 與 Snowflake 的權限子頁，都沒有讀到。ServiceNow 那篇是社群網站上的文章，作者是不是官方帳號看不出來，留言區有人對「不繞過安全」的說法提出質疑，那是使用者留言。

下次有人說 ontology，或說 semantic layer，或說 knowledge graph，先別急著判斷他說的是哪一家的東西。同一個字，可以是詞彙加 reasoner，可以是指標加查詢，也可以是 object、link、action type 加 function；先問他的文件怎麼回答那四題，答案才會出現。

常見問題

Q：遇到別人說 ontology 或 semantic layer，怎麼判斷他說的是哪一種？ 本文的整理是問四題：文件叫你定義的基本單位是什麼，消費端拿定義去做什麼，有沒有形式推論，動作住在哪裡，外加權限掛在哪一層。這四題不是任何一家或標準的官方分類，只比官方文件自己怎麼寫；文件沒寫的格子，本文標「頁面沒寫」。

Q：Palantir 的 Ontology 跟 W3C 的 OWL 2 ontology 是同一種東西嗎？ 兩邊文件寫的重心不同。W3C 的 OWL 2 文件把 ontology 寫成有形式化語意的詞彙，並提到 reasoner 依語意推導；Palantir 文件叫使用者定義 object type、link type、action type 與 function。本文讀的 Palantir 十頁正文未出現 OWL、RDF、SHACL 這些 W3C 詞彙，這是本批快照的字串結果，不是 Palantir 全部文件的結論。

Q：Microsoft Fabric IQ 的 ontology 算不算 semantic layer？ 專頁在 2026 年 9 月查閱時仍標 preview，文件自稱是 semantic modeling layer，也寫可以從 semantic model 生成。本文的讀法是它在四題上落在 semantic layer 家族旁邊，但專頁另有自然語言 rule、RDF 與 OWL 匯入這些 semantic layer 家族頁面沒寫的東西；規則頁寫 ontology 不執行規則與 action。

Q：semantic layer 只能讀資料、不能觸發動作嗎？ 本文讀到的文件不支持這種全稱說法：Looker 有欄位層級的 action 參數，由接收端伺服器執行；dbt 的 exports 把查詢結果寫成同一個資料平台裡的表或視圖。兩者類型不同，也都不等於 Palantir 把 action type 當成定義單位的寫法。