The W3C's Ontology Is for Inference; Palantir's Defines Actions

本文另有中文版：同叫 ontology：W3C 拿來推論，Palantir 把動作寫進定義

The OWL 2 Primer is the W3C’s own introduction to its ontology language, and the paragraph that introduces the term follows its first sentence with a caveat: “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”.

Documentation from three other camps shows why the caveat matters. Cube’s introduction page calls its data model a knowledge graph. Microsoft’s Fabric IQ page describes its ontology as a semantic modeling layer. Palantir’s architecture page says the Ontology is not a “semantic layer” because a thin semantic layer cannot do the four-way integration of data, logic, action and security. The same page then uses the word semantic for the Ontology’s own parts.

Names alone settle little, so this piece asks four questions of each document instead. What is the basic unit the document tells the reader to define? What does the consuming side do with the definition? Is there formal inference? Where do actions live? Where permissions attach is a fifth check.

The answers sort the documents into three groups: the W3C’s OWL 2, a vocabulary for reasoners; Palantir, with its object, link and action types; and the semantic layer family of dbt, Cube and LookML, which defines metrics and dimensions for queries. Fabric IQ’s ontology lands beside the last group, despite its name. The questions and the groups are this piece’s own organization. No vendor or standard publishes them as a classification.

This is part 4 of a series, after part 1, part 2 and part 3; part 3 ended on the question this piece takes up.

Cube’s Data Model Is a Knowledge Graph; Fabric IQ’s Ontology Is a Layer

Cube’s introduction page describes Cube as an agentic analytics platform built on an open-source semantic layer. A few lines further down, it describes the data model this way: “The data model is the knowledge graph the platform — and any AI agent — uses to understand your business.” That is the only use of the phrase in the three Cube pages read; the data-model and access-policies pages do not use it.

dbt reaches for a graph word without the knowledge label: “Think of semantic models as nodes connected by entities in a semantic graph.” Semantic models are the nodes, and entities connect them.

Microsoft’s Fabric IQ page goes the other direction. The item is named ontology, and the page places it in the stack as a layer: “Ontology is the business context and semantic modeling layer between enterprise data and the experiences that consume it.” The same page says an ontology can be built from scratch or generated directly from semantic models. The page labels the item preview, and everything this piece says about Fabric IQ’s ontology refers to that preview.

Palantir takes the opposite position on the label. Its architecture page states: “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.” Part 1 read that sentence as a boundary claim. Here the second clause matters, because the objection is to a thin semantic layer that cannot carry four kinds of integration.

The word semantic still runs through Palantir’s description of itself. The architecture page says the Ontology’s Language models semantic objects, links and properties, along with kinetic actions and automations. The why-ontology page calls a semantic model combined with decision logic valuable, but ultimately limited unless the executed decisions can be synchronized with operational systems in a way that compounds. The overview page calls the Ontology an operational layer and, in many settings, a digital twin of the organization.

An article on the ServiceNow Community site, dated November 17, 2025, uses all three terms; the snapshot does not show whether the author’s account is official. It calls a knowledge graph a semantic overlay that helps AI understand how a business works, calls the structure that defining one produces an ontology, and explains how it works under a heading about the semantic layer. It also says: “Knowledge Graph does not store new data, duplicate information, infer relationships, or bypass security.”

The word ontology itself is unevenly spread. It does not appear on the six dbt, three Cube or eight Looker pages read, or on the Databricks, Snowflake and Microsoft semantic model pages, while the Fabric IQ and Palantir pages use it throughout. C3 AI’s marketing page also describes modeling the enterprise as a unified ontology graph, which is marketing wording, not technical documentation.

Four Questions Sort the Documents Into Three Groups

The fourth question is worded with care. It does not ask whether a product has actions at all, since Looker has an action parameter on fields and dbt has exports. It asks whether the action is a first-class type in the definition, which lets Looker, dbt and Palantir each sit where their own documents put them.

Asked of every source, the four questions give three groups:

Fabric IQ’s ontology sits beside the third row: its units include entity types and metrics, and its consumers query the sources themselves. Its page also carries things the third group’s pages do not, covered below. The full six-source table is in the appendix.

OWL 2 Defines a Vocabulary for Reasoners, Not a Database

The OWL 2 Overview defines ontologies as formalized vocabularies of terms, often covering a specific domain and shared by a community of users. Read together, the Overview and the Primer give the basic units as classes, properties and individuals, and the Primer calls the statements among them axioms.

The consuming side is a reasoner. The Primer says: “Appropriate tools (so-called reasoners) can then be used to infer further information about that state of affairs.” The Overview names two formal semantics and says reasoners and other tools use them. Inference is the core of the OWL 2 picture.

The Primer also lists what OWL 2 is not, and the warnings fit habits from other camps. “OWL 2 is not a database framework.” A database usually treats a missing fact as false, which the Primer calls the closed-world assumption; OWL 2 follows the open-world assumption, where a missing fact may simply not have been stated.

Two more warnings follow. OWL 2 is not a schema language for syntax conformance, so there is no way to enforce that a piece of information, such as a person’s social security number, is syntactically present. And OWL does not assume that different names refer to different individuals, so two identifiers may name the same thing.

Checking the shape of data belongs to another W3C standard. SHACL is “a language for validating RDF graphs against a set of conditions”, and its descriptions can also serve user interface building, code generation and data integration. SHACL implementations may, but need not, support entailment, and a shapes graph can declare the inferencing it requires through sh:entailment.

The Primer draws one more line: “note that a domain (or range) statement is not a constraint on the knowledge, but allows a reasoner to infer further knowledge”. Set beside SHACL, that gives a contrast this piece draws, not the W3C: a statement that looks like a schema rule is inference in OWL 2 and a constraint in SHACL.

As for actions, the W3C pages center on vocabularies, graph data and validation. They do not describe taking actions against outside systems.

Semantic Layers Define Metrics and Dimensions, Then Compile Queries

dbt’s units need a version attached. The MetricFlow page defines entities in graph language: “Entities: The join keys of your semantic model (think of these as the traversal paths, or edges between semantic models).” The semantic models page marks its blocks as applying to dbt v1.12 and later, and its example YAML uses simple metrics, with a comment reading Simple metrics replace measures. On that page, the units are semantic models holding entities, dimensions and simple metrics, plus metrics as their own definitions.

Cube’s units are cubes and views. Its introduction says cubes represent business entities such as customers, orders and line items, and that they define measures, dimensions and the joins between entities. Cube calls its model dataset-centric, an expansion of dimensional modeling. Looker’s LookML page calls LookML the language for creating semantic data models, built from dimensions, aggregates, calculations and data relationships. The wording differs from page to page, but the shapes overlap.

The consuming side is where the documents get concrete. dbt describes a query planner: “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.” Downstream tools reach those definitions through GraphQL and a JDBC driver.

Cube puts a checkpoint between the consumer and the warehouse: “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.” AI agents connect through Cube’s MCP server or Chat API and get answers grounded in the same governed data model.

Snowflake’s semantic views page also lists agents, saying the views can be used in Cortex Agents and queried in a SELECT statement. It adds: “Semantic views improve accuracy by combining LLM reasoning with rule-based definitions.” In this piece’s reading, that is a language model’s reasoning, not formal inference in the W3C sense.

That rules out a common shortcut, the idea that the camps differ in whether the consumer is an AI agent. Cube, Snowflake, Fabric IQ and Palantir all list agents. The difference this piece reads is what the consumer does with the definition. In dbt and Cube, the definition is used to compile and constrain queries. In OWL 2, a reasoner derives new statements from axioms. In Palantir’s documents, applications and agents read and write objects and invoke actions.

Three items in the same documentation push back on that summary, and each is a different kind of thing.

Looker’s action parameter sends a request to a receiving server

Looker’s action parameter page states: “The action parameter creates a data action that lets users perform field-level tasks in other tools, directly from Looker.” The action sits on a dimension or measure, the receiving server must be able to accept a JSON POST, and a successful HTTP response counts as a successful action. The receiving server can also send back validation errors for form parameters. The definition is written in terms of the outgoing request and the answer that comes back. The action hub page treats its own actions as a separate route from these data actions.

A Looker best-practices page on write-back is easy to misread. It says: “Through its Action API, Looker supports this use case for any data warehouse or destination.” What the page then walks through is narrower: customers on Google Cloud deploy a demo action on Cloud Run functions to write back to BigQuery. The demo derives current-state tables from an append-only log at query time, and its handler checks a secret token before accepting a request. Those are the demo’s design choices, not built-in Looker features and not Looker rules.

The data-action, action-hub and write-back pages do not discuss transactions, rollback, idempotency or action auditing on Looker’s side, and no audit-log page was captured. The closest thing to a record is in the action hub page’s testing section, where a test action’s status appears in the Scheduler History in the Admin panel.

dbt exports write a table inside the same data platform

The exports page says: “Exports enhance saved queries by running your saved queries and writing the output to a table or view within your data platform.” An export runs a create-table statement, so the data stays in the platform, and it is a leaf node in the DAG that other models cannot reference with ref. The page lists dbt 1.7 or newer as a prerequisite.

So exports write query results inside the platform that already holds the data, while a Looker data action sends a request out. Pages on dbt’s GraphQL, JDBC and SDK interfaces and on permission details were not captured, so nothing here covers dbt writing to outside systems.

Cube uses “knowledge graph” once, for its data model

Cube’s introduction says its semantic layer is built on four pillars: data modeling, access control, caching and APIs. The knowledge graph sentence sits under data modeling, and the sentence after it says what the model holds: “It defines metrics, entities, joins, and how they relate, upstream of any consumer.” Access control, another pillar, runs at the same layer, so every consumer gets the same policies.

The three cases share one feature. Their definition sentences are about queries, requests and tables. The center of the semantic layer definition is not the action.

Palantir Puts Action Types in the Definition

Palantir’s core-concepts page opens broadly: “An Ontology is a categorization of the world.” It maps datasets and models to object types, properties, link types and action types, and suggests thinking of each object type as analogous to a dataset.

The same page defines each unit in one sentence. An object type defines an entity or event in an organization, and a link type defines the relationship between two object types. The third is where Palantir’s documents depart from the three semantic layer cases above: “An action type defines how an object type can be modified.” Functions sit beside these types, as covered in part 1.

The overview page sorts the contents into semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security), and the architecture page says semantics must be paired with kinetics. The overview also sets the Ontology apart from data cataloging and schema design tools, as a foundation for end-user workflows.

The action-overview page says: “An action is a single transaction that changes the properties of one or more objects, based on a user-defined logic.” The action type also includes the side effects that occur when an action is submitted, and the side-effects page says they can write to other source systems in the organization. Part 2 walked through the transaction.

The webhooks page sets two modes side by side. A writeback webhook runs before object changes; a side effect webhook runs after them, and the page’s table, in its column on whether failure is shown to the end user, reads Yes for writeback and No for side effect. For writeback, the page says: “Using a writeback webhook guarantees that if the request to the external system fails, no changes will be applied to the Foundry Ontology.” It adds that the external request may still succeed while the Ontology changes fail, and calls the arrangement some degree of transactionality.

Set against Looker, this piece reads a difference in document structure, not in capability. Looker’s data action is defined by the request that goes out (label, URL, parameters, form). A Palantir action type is defined by the changes it makes to Ontology objects, properties and links, with a notification or webhook optionally attached. It is also a difference in disclosure: Palantir wrote down its own limits on external writes, and the Looker pages do not take up the question. Neither amounts to a proven end-to-end transaction guarantee.

The consuming side is people, developers and agents. The OSDK page says it gives access to the full power of the Ontology directly from a development environment, and the why-ontology page says: “the decision-centric Ontology connects humans and agents directly to operations”.

Permissions need two pages, written for different situations. The permissions page says project-based permissions are enabled for new ontologies; for existing ontologies an owner must enable them manually and existing resources require migration; and they are not yet available for Default Ontologies. It says this approach replaces the earlier models of ontology roles and datasource-derived permissions. The core page still states: “Roles are the central permissioning model in the Ontology.” Neither page says what share of ontologies has migrated.

The formal-inference question has the narrowest answer. The ten Palantir pages read (why-ontology, overview, core, architecture, object types, actions, webhooks, side effects, permissions and OSDK) do not contain OWL, RDF, SPARQL, triple, knowledge graph, inference, entailment, reasoner or SHACL. Reasoning does appear, in the sense of decision logic or model reasoning, as in “the non-deterministic reasoning of LLMs”.

An interoperability page says every element of an organization’s Ontology can be accessed through REST APIs and configured through JSON-driven authoring, and then: “This allows for bidirectional synchronization with existing semantic modeling tools, ontologies resident within data catalogs, and domain-specific modeling tools.” The wording is allows for. The page says synchronization is possible, and does not say which formats are used, how fidelity is kept, or which mechanism does the work.

Palantir’s export page stores Ontology schema definitions in a JSON file and warns: “You should not depend on the exported JSON schema as it may change over time.”

Fabric IQ’s Ontology Can Be Generated From Semantic Models

Microsoft’s ontology page describes the item as a shared, machine-understandable representation of a business. A June 2 blog post from Microsoft Build 2026 says ontologies are “expected to be generally available in the coming months,” while the page still carried the preview label on the day it was captured.

The units are entity types, properties, relationships, metrics and rules. An entity type is a reusable definition of a business concept such as Customer, Shipment, Machine or Store, and a metric is a governed calculation tied to ontology concepts. The rule is different: “A rule is a natural-language statement of business logic linked to ontology concepts.” In this piece’s reading, entity types and metrics resemble what the semantic layer family defines, and the page itself says the ontology aligns with familiar semantic-model constructs while extending them. The natural-language rule does not appear in the semantic layer definitions read.

On the consuming side, the page describes a store of definitions. It says the ontology “isn’t itself a general-purpose data-query engine”; source data stays in the system that owns it, and consuming experiences can query the live bound source instead of copying all data into the ontology. A graph layer is optional, for cases where the relationship path itself matters, and an ontology-derived schema graph does not load instance data by default. Access comes in two layers: Fabric workspace and item permissions control the ontology items, and access to bound data follows the source’s own security.

The W3C connection is explicit: “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.” The page does not use the words inference, reasoner or entailment; reasoning appears once, where a rule is made available to consumers during reasoning. Palantir’s export page, by contrast, describes its own JSON schema. That sets two documents side by side; it does not compare capabilities.

Actions need the most care, because three Microsoft documents name three different subjects. The rules page’s subject is the rule: “A business rule is a natural-language definition. Ontology doesn’t run the rule against data or execute actions.” The same page notes that the new ontology experience does not currently provide direct integration with Activator.

The overview page’s subject is agents: “Ontology grounds agents in shared business language and rules so they can reason across domains and trigger governed actions.” The agent does the triggering. The ontology page’s core-concepts list (entity type, instance, property, relationship, metric, rule, namespace, data binding) has no action.

The Build post’s subject is ontologies: “They define business entities, relationships, properties, rules, and actions, and connect to live signals from Fabric Real-Time Intelligence.” The post does not say what actions means, who executes them or how they are authorized.

The Three Groups Have Crossing Points

In this piece’s reading, three documents show that the groups are not sealed off from each other. Fabric IQ can generate an ontology from semantic models and can also import OWL. dbt’s MetricFlow page says: “MetricFlow is developed and maintained by dbt Labs and works with the Apache Ossie format.” The page does not say what Ossie is; the semantic models page describes it as an alternative to dbt’s native YAML.

A Snowflake blog post dated September 23, 2025 says: “The OSI initiative is a collaborative, open-source effort dedicated to standardizing and streamlining semantic model exchange and utilization”. Its partner list that day included Cube, dbt Labs, Salesforce and ThoughtSpot, and it closed by asking readers to stay tuned as the OSI takes shape. That was a 2025 initiative, not a 2026 status report. Ossie and OSI appear in two different documents, and the snapshots do not connect them.

What Separates Palantir From the Semantic Layer Is the Action Type

Each question splits the documents in a different place. The basic unit splits them roughly in half: terms and axioms for OWL 2, four kinds of type for Palantir, and metrics, dimensions and entities, or their near relatives, for the rest. The consumer and inference questions pull out the W3C, the one group compared here where the consumer derives and formal inference is the core. The word reasoning does not settle it, because it means a reasoner working from axioms in OWL 2, a language model on Snowflake’s page, and decision logic or a language model on Palantir’s.

The action question pulls out Palantir. In its documents, the action type is part of the definition. In Looker, an action is a parameter on a field that a receiving server executes; in dbt, an export writes a table inside the platform; on Fabric IQ’s rules page, the ontology does not execute rules or actions. Fabric IQ’s ontology stays beside the semantic layer family on all four questions.

So Palantir and the semantic layer family do not part ways over the word semantic, which both use. They part ways over whether the action is written into the definition. And a product named ontology can still sit beside the semantic layer family, as Fabric IQ’s does. This series is about Palantir, so when someone says ontology, the question to ask first is where the actions live. The name alone is not enough to answer it.

Scope and Versions

This piece compares what each document says, not what each product can do. All pages were captured on September 29, 2026, and pages change. “Not stated” means not stated on the pages read, which is not the same as the product cannot do it.

The Palantir findings cover the ten pages listed above. The Fabric IQ findings cover the preview ontology page, the rules page, the overview page and the June 2, 2026 Build post. The Snowflake post is dated September 23, 2025, and these pages cannot say whether the OSI produced anything since or whether its partner list changed. Pages not captured include dbt’s GraphQL, JDBC, Python SDK and permission subpages; Cube’s Scheduled Tasks, Notifications and Agent skills pages; Databricks and Snowflake permission subpages; and a Looker audit-log page. SHACL, RDF 1.1 and the OWL 2 Overview were read only in part. The ServiceNow piece is an article on a community site, and the snapshot does not show whether its author’s account is official.

Each reading here has a condition that would overturn it. If other pages document consumers using definitions differently, the reading that the camps differ in what consumers do with definitions would have to change. If Looker documentation elsewhere defines explicit transaction semantics, the Looker–Palantir comparison would have to change. If Fabric IQ documentation defines actions or inference as first-class types, its place beside the semantic layer family would have to change. The crossing-points summary covers only these sources; if later documentation shows different exchange formats or scopes, it would have to change.

Appendix: The Six Sources Side by Side

The table answers the four questions and the permission check for each source. “Not stated” has the meaning given in Scope and Versions.

Next in this series: Palantir’s Row-Level Permissions End at the Read. Markings Don’t.

Frequently Asked Questions

Q: Is an ontology the same thing as a semantic layer? Not by name alone. Across the documents read, the W3C uses ontology for a formal vocabulary that reasoners can infer from, dbt, Cube and Looker define metrics, dimensions and entities for queries, and Palantir defines object, link and action types while stating that its Ontology is not a “semantic layer,” because a thin semantic layer cannot do the four-way integration of data, logic, action and security. Fabric IQ’s ontology (preview) is described as a semantic modeling layer. The four questions in this piece are its own reading, not an official classification.

Q: Does Palantir’s Ontology use OWL or RDF? The ten Palantir pages read for this piece do not contain OWL, RDF, SPARQL, SHACL, reasoner or entailment. One interoperability page says REST APIs and JSON-driven authoring allow for bidirectional synchronization with existing semantic modeling tools; it does not say which formats or how. The export page describes Palantir’s own JSON schema and warns that it may change.

Q: Can a semantic layer trigger actions? The pages read do not put actions at the center of semantic layer definitions. Looker’s action parameter sends a request to a receiving server, and dbt exports write a table or view inside the same data platform. These are different kinds of thing, and the absence of such features on the pages read does not mean the products cannot do it.

Q: Which four questions separate the meanings? What is the basic unit the document tells you to define, what does the consuming side do with the definition, is there formal inference, and where do actions live. Permissions are a fifth check. These questions are this piece’s own organization, based on the documents read, and are not any vendor’s or standard’s classification.