同叫 ontology：W3C 拿來推論，Palantir 把動作寫進定義

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。Microsoft Fabric IQ 的 ontology 專頁，說 ontology 是一層 semantic modeling layer。Palantir 的文件寫 Ontology 不是 semantic layer，理由是 thin semantic layer 做不到四項整合，但同一份文件也用 semantic 這個字描述自己。

名稱不足以單獨判別，所以本文改問四個問題：文件叫你定義的基本單位是什麼？消費端拿定義去做什麼？有沒有形式推論？動作住在哪裡？問完之後，這批文件分成三頭：W3C 是詞彙加 reasoner，Palantir 是 object、link、action type 加 function，dbt、Cube、LookML 這些 semantic layer 是指標、維度、實體加查詢。Fabric IQ 的 ontology 名字叫 ontology，在四題上卻落在第三頭旁邊。四題與三頭都是本文的整理，不是任何一家或任何標準的官方分類。

這是系列第四篇（前三篇：第一篇、第二篇、第三篇），回答第三篇結尾預告的那一題。

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 官方文件，intro 頁）同一頁又說 Cube 建在開源的 semantic layer 上，兩個詞在同一頁並存。本文讀的 Cube 三頁裡，knowledge graph 只在 intro 頁出現這一次，資料模型頁與 access policies 頁都沒有。

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

Fabric IQ 的專頁把方向反過來：名字叫 ontology，自稱是一層。專頁寫：“Ontology is the business context and semantic modeling layer between enterprise data and the experiences that consume it.”（Microsoft 官方文件，Fabric IQ ontology 頁）同一段接著說它本身不是通用的資料查詢引擎，另一處又稱它是疊在來源資料上的一層虛擬的 semantic 與 context layer。專頁也寫 ontology 可以從頭建，也可以直接從 semantic model 生成。這份專頁在查閱時標的是 preview，本文提到的 Fabric IQ ontology 都指這個 preview 狀態。

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

ontology 這個詞的分布很不平均。本文讀的 dbt 6 頁、Cube 3 頁、Looker 8 頁、Databricks 1 頁、Snowflake 2 頁與 Microsoft semantic models 頁，一次都沒出現 ontology；Fabric IQ 與 Palantir 的頁面則通篇在用。

Palantir 說 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 官方文件，arch-ontology-system 頁）否定的對象是 thin semantic layer，理由是四項整合做不到。這句話比「Ontology 不是 semantic layer」長，也比它窄。

同一頁稍後就用了這個字。它說 Language 建模的是 semantic 的物件、連結與屬性，再加上 kinetic 的動作與自動化；另一處寫 semantics 必須與 kinetics 配對。semantic 是 Palantir 描述自己的詞，kinetic 是它的另一半。

why-ontology 頁的說法也是這樣。它說把資料統一在 semantic model 裡、再配上評估決策所需的邏輯，是有價值的；但除非執行過的決策能以會累積的方式與營運系統同步，每個決策都在同一條 lineage 裡影響下一個，否則終究有限。受限的是只停在這一步，semantic model 本身仍被說成有價值。overview 頁則把 Ontology 稱為 operational layer，並寫在許多情境下它充當組織的 digital twin。

四個問題把這批文件分成三頭

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

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

四題問下來，三頭是這樣分的：

Fabric IQ 的 ontology 落在第三頭旁邊：單位裡有 entity type 與 metric，消費端自己對來源資料查詢。專頁另有第三頭頁面沒寫的東西，後面一節交代。六種文件逐格的完整對照表放在文末附錄。

W3C 的 ontology 是給 reasoner 推導的詞彙，不是資料庫

OWL 2 Overview 頁把 ontologies 定義成形式化的術語詞彙，通常涵蓋某個領域，由一群使用者共享。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）Overview 頁也提到兩套語意，並寫 reasoner 與其他工具使用這兩套語意。第三題的答案在這一頭是有，而且是核心。

Primer 同時劃了幾條線，免得讀者把 OWL 當成別的東西。第一條是資料庫：“OWL 2 is not a database framework.”（W3C OWL 2 Primer）資料庫通常把缺的事實當作假，這叫 closed-world assumption；OWL 依 open-world assumption，缺的事實可能只是沒寫出來。

第二條是 schema 與名字。Primer 說 OWL 2 不是檢查語法的 schema 語言，沒辦法強制某項資料（例如一個人的社會安全號碼）在語法上一定要出現。OWL 也不假設不同的名字就指不同的個體，兩個名字可能指同一個個體。

資料形狀的驗證是另一個標準 SHACL。SHACL 頁說它是依一組條件驗證 RDF 圖的語言，而這些描述除了驗證，也可以用於建使用者介面、生成程式碼與資料整合。SHACL 的實作可以、但不必支援 entailment，並提供 sh:entailment 標明一個 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）。把這句與 SHACL 接起來是本文的整理，不是 Primer 的話：同樣長得像 schema 的語句，在 OWL 裡是推論，在 SHACL 裡是約束。

第四題呢？本文讀到的 W3C 頁面，範圍描述圍繞詞彙、圖資料與驗證，沒有寫對外部系統下動作。

dbt、Cube、LookML 定義指標、維度與實體，拿定義編譯並限制查詢

dbt 的單位要逐頁標版本。MetricFlow 頁把 entity 定義成 join key：“Entities: The join keys of your semantic model (think of these as the traversal paths, or edges between semantic models).”（dbt 官方文件，MetricFlow 頁）

semantic models 頁的區塊標著適用 dbt v1.12 以後，該頁的範例 YAML 已改用 simple metrics（註解寫 Simple metrics replace measures）。所以照這一頁，單位是 semantic model（含 entities、dimensions、simple metrics）加 metrics。消費端怎麼用這些定義？MetricFlow 頁說，產生一個 metric 時，它用自己的 SQL 引擎，依 semantic model 與 metric 的 YAML 定義，找出表與表之間最好的路徑。定義被拿來規劃 SQL；下游工具則經 GraphQL 與 JDBC driver 查詢 metrics 與 dimensions（Semantic Layer APIs 頁）。

Cube 的單位是 cubes 與 views。intro 頁說 cubes 代表客戶、訂單、訂單明細這類業務實體，定義 measures、dimensions 與實體之間的 join；Cube 也說自己的模型以資料集為中心，延伸自 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.”（Cube 官方文件，intro 頁）定義是查詢路徑上的一道關卡：先驗證，再套用政策，才到 warehouse。

權限也掛在這一層。intro 頁說存取控制跑在 semantic layer，所以 AI agent、BI 工具、嵌入式應用吃到的是同一套政策；access policies 頁說，以 group 為範圍的政策把 member 存取、row filter 與 masking 規則直接寫進資料模型。這些政策掛在 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、Snowflake 與 Microsoft 的頁面。Databricks 的 metric views 頁把 measure 與維度欄位分開定義；Snowflake 的 semantic view 是 schema 層級的物件，文件說它算 metadata；Microsoft 那頁是 Fabric warehouse 章節，把 Power BI semantic model 說成對分析領域的邏輯描述。

Snowflake 頁也寫了 AI 的用法：semantic view 可以用在 Cortex Agents，也能在 SELECT 語句裡查詢。頁面還寫：“Semantic views improve accuracy by combining LLM reasoning with rule-based definitions.”（Snowflake 官方文件）這裡的 reasoning 指的是 LLM 推理，本文的判讀是它不是 W3C 意義的形式推論。

到這裡可以整理消費端。Cube、Snowflake、Fabric IQ 的 overview 頁與 Palantir 都把 AI agent 列為消費者，所以「消費端是不是 agent」分不出差別。本文的讀法是，差別在消費端拿定義去做什麼：dbt 與 Cube 拿定義編譯並限制查詢，W3C 的 reasoner 依公理推導，Palantir 的應用程式與 agent 讀寫物件並叫用 action。

Looker 有 action、dbt 會寫表，但動作在這兩家都不是定義裡的型別

讀到這裡，有人會反駁：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 官方文件，param-action 頁）動作掛在 dimension 或 measure 上，接收端伺服器必須能接受 JSON POST；成功的 HTTP 回應就算動作成功，接收端也可以對表單參數回傳 validation errors。所以 Looker data action 的定義寫的是送出去的請求：label、url、param、form，由接收端伺服器執行。action hub 頁另外說明，經 action hub server 提供的 actions 與 action 參數定義的 data actions 不同，兩條線是文件自己分開的。

寫回資料倉儲的頁面要小心讀。Looker 官方 best-practices 頁寫：“Through its Action API, Looker supports this use case for any data warehouse or destination.”（Looker 官方文件，BigQuery 寫回頁）但這一頁實際教的是：使用 Google Cloud 的客戶，把官方附的 demo 程式部署到 Cloud Run functions，寫回 BigQuery。寫入由客戶部署的服務執行，不是 Looker 本體內建的功能。這個 demo 只 append 資料列，頁面說現況可以在查詢時從 append-only 的 log 推導出來、模擬更新；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 官方文件，exports 頁）它直接執行 create table，資料留在同一個資料平台裡；export 是 DAG 的葉節點，別的 model 不能用 ref 接回去。exports 頁的先決條件寫 dbt 1.7 以上。

dbt exports 寫進的是同一個資料平台，Looker action 送請求給接收端，兩者不同類。至於 dbt 對外部系統的動作，GraphQL、JDBC、Python SDK 的子頁與權限細節頁沒有快照，本文讀到的頁面沒寫。

第三個是 Cube 自稱 knowledge graph。那句前面引過，這裡只補範圍：它指的是資料模型，而資料模型的單位仍是 cubes 與 views。

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

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

Palantir 對自己的定義寫在 core 頁：“An Ontology is a categorization of the world.”（Palantir 官方文件，core 頁）同頁說明它把資料集與模型對應到 object types、properties、link types 與 action types，並說每個 object type 可以想成類似一個資料集。overview 頁則說，Ontology 遠不只是資料目錄或 schema 設計工具，而是讓你為終端使用者的工作流程定義穩固的基礎。

core 頁對三種單位各給一句定義：object type 定義組織裡的一個實體或事件，link type 定義兩個 object type 之間的關係，而 “An action type defines how an object type can be modified.”（core 頁）action type 與 object type、link type 並排，是定義裡的一等型別，這與前面三個反駁的結構不同。

overview 頁把 Ontology 描述成同時含 semantic 元素（objects、properties、links）與 kinetic 元素（actions、functions、dynamic security），function 也在 kinetic 這一半。action-overview 頁寫 action type “also includes the side effect behaviors that occur with action submission.”（Palantir 官方文件，action-overview 頁）動作、規則與副作用寫在同一個定義裡，第二篇拆過；side effects 頁也寫，副作用可以寫到組織裡的其他來源系統。

外部系統的交易性，webhooks 頁分兩型寫。writeback 型：外部請求失敗，Ontology 就不套用任何變更；但外部請求成功而 Ontology 變更失敗仍有可能，文件形容這是某種程度的 transactionality。side effect 型：在物件變更之後執行，webhooks 頁的表格寫失敗不會顯示給終端使用者（「失敗是否顯示給終端使用者」一欄，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 官方文件，action webhooks 頁）

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

消費端這一題，Palantir 的答案是應用程式、SDK 與 agent。OSDK 頁說，開發者可以直接從自己的開發環境存取 Ontology 的完整能力；why-ontology 頁寫：“the decision-centric Ontology connects humans and agents directly to operations”（Palantir 官方文件，why-ontology 頁）。本文的讀法是人與 agent 讀寫物件並叫用 action。

權限這一格要兩頁一起看，因為兩頁描述的對象不同。permissions 頁說，專案式權限對新的 ontology 是啟用的；既有 ontology 要由 owner 手動啟用，既有資源需要遷移；Default Ontologies 還不能用。同頁說這套專案式做法取代先前的 ontology roles 與 datasource-derived permissions。core 頁則仍寫：“Roles are the central permissioning model in the Ontology.”（core 頁）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 官方文件，why-ontology 頁）；arch 頁另有 decision graph 這個詞，指的也是決策。

互通頁說，Ontology 的所有元素都能經 REST API 存取、用 JSON 驅動的方式設定，接著寫：“This allows for bidirectional synchronization with existing semantic modeling tools, ontologies resident within data catalogs, and domain-specific modeling tools.”（Palantir 官方文件，interoperability 頁）文件只說這使雙向同步成為可能，格式、保真度與機制都沒寫。

匯出入頁說 Ontology 的 schema 定義存在一個 JSON 檔裡，同時提醒：“You should not depend on the exported JSON schema as it may change over time.”（Palantir 官方文件，ontology export／import 頁）匯出入的是自家 JSON，文件也提醒不要依賴那份 schema 的穩定。

Fabric IQ 的 ontology 可以從 semantic model 生成，rule 用自然語言寫

專頁開頭說，Fabric IQ 的 ontology（preview）提供一份共享、機器可理解的業務表示。單位有 entity type、property、relationship、metric、rule：entity type 是業務概念可重用的定義，例如 Customer、Shipment、Machine、Store；metric 是掛在 ontology 概念上的受治理計算；而 “A rule is a natural-language statement of business logic linked to ontology concepts.”（Microsoft 官方文件，Fabric IQ ontology 頁）

專頁也說，ontology 與熟悉的 semantic model 結構對齊，再用 ontology 專屬的建模概念去延伸。單位裡有 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 是選配的執行層，用在關係路徑本身重要的情境，而且從 ontology 衍生的 schema graph 預設不載入實例資料。專頁的核心概念清單另有 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 官方文件，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 官方文件，Fabric IQ overview 頁）trigger 的是 agents。專頁的 Core concepts 清單則只列 entity type、instance、property、relationship、metric、rule、namespace 與 data binding，沒有 action。

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）發表文把 actions 列進 ontology 的定義裡；actions 指什麼、由誰執行、如何授權，這份文章沒寫。

三頭的邊界有交會處：Fabric IQ 可以從 semantic model 生成，又能匯入 OWL

上面幾節看起來像三頭各有陣地，但幾份文件顯示邊界沒有那麼乾淨。Fabric IQ 的 ontology 可以從 semantic model 生成，也能匯入 OWL。dbt 的 MetricFlow 頁寫：“MetricFlow is developed and maintained by dbt Labs and works with the Apache Ossie format.”（dbt 官方文件，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），結尾請讀者等 OSI 成形後的更新。發文當日的夥伴名單列了 Cube、dbt Labs、Salesforce、ThoughtSpot 等，但這是 2025 年 9 月的倡議，不是 2026 年 9 月的現況。Ossie 與 OSI 兩個名字出現在兩份不同的文件裡，快照沒有把它們連起來。

本文的整理是：這三份文件顯示，本文所比較的概念邊界並非彼此隔絕。

把 Palantir 和 semantic layer 家族分開的，是寫進定義的動作

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

動作這一題把 Palantir 分出來。Palantir 的動作是定義裡的型別；Looker 的動作是欄位上的參數，執行在接收端；dbt 的動作是寫進同一平台的表；Fabric IQ 規則頁寫 ontology 不執行規則與 action。

照這四題看，Palantir 與 semantic layer 家族的差別，不在 semantic 這個字，兩邊都在用；差別在 action type 寫進了定義。叫 ontology 的東西，也可以像 Fabric IQ 那樣落在 semantic layer 家族旁邊。這個系列談的是 Palantir，所以別人說 ontology 時，最該先追問的是第四題：動作有沒有寫進定義。名字本身不足以回答這一題。

範圍與版本

本文只比官方文件自己怎麼寫，不比產品實際做得到什麼。頁面抓於 2026 年 9 月 29 日，之後會變；文中的「頁面沒寫」指本文讀到的頁面沒寫，不等於做不到。

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

Databricks 與 Microsoft 各只讀一頁（入口或章節性質），Snowflake 讀了兩頁（semantic views 概述頁與 OSI blog），這三家的權限與動作，頁面沒寫。沒讀到的頁面：dbt 的 GraphQL、JDBC、Python SDK 與權限子頁；Cube 導覽列的 Scheduled Tasks、Notifications、Agent skills 頁；Databricks 與 Snowflake 的權限子頁；Looker 專門的 audit-log 頁。W3C 的 SHACL、RDF 與 OWL 2 Overview 只讀了一部分。ServiceNow 那篇是社群網站上的文章，留言區有人對「不繞過安全」的說法提出質疑，那是使用者留言。

本文的幾個讀法各有推翻條件：若某家文件把消費端另寫成別的用法，「差別在消費端拿定義做什麼」這個讀法就要改；若 Looker 另有文件寫了 transaction 語意，Looker 與 Palantir 的對照就要改；若 Fabric IQ 的文件把 action 或推論寫成一等型別，「Fabric IQ 落在第三頭旁邊」就要改；若後續文件顯示交換的對象與格式另有主張，「邊界有交會處」的整理也要改。

附錄：六種文件的對照表

下表把前面各節的格子放在一起，列是六種文件，欄是四題加權限；格子裡的「頁面沒寫」意思同上一節。

本系列下一篇：Palantir 的 row 權限停在讀取當下，markings 預設跟著資料走。

常見問題

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 當成定義單位的寫法。