"Ontology" Has a Complex History, Says the W3C; Cube Calls Its Data Model a Knowledge Graph

本文另有中文版：同名異物：W3C 說 ontology 歷史複雜，Cube 把資料模型叫 knowledge graph

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, then uses the word semantic for the Ontology’s own parts.

Names alone therefore settle little.

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? A fifth check, where permissions attach, rides along in the comparison table.

The four questions, and the three groups they sort the documents into, are this piece’s own organization. No vendor or standard publishes them as an official classification. The groups are the W3C’s OWL 2 with its reasoners, Palantir with its object, link and action types, and the semantic layer family of dbt, Cube and LookML. Fabric IQ’s ontology lands beside the last group, despite its name.

This piece compares what each document says, not what each product can do. The reader’s problem is narrower: when someone says ontology or semantic layer in a meeting, which thing is meant? This piece follows part 1, which read Palantir’s statement that the Ontology is not a semantic layer, and its reason, part 2, which followed one action from definition to logging, and part 3, which checked how far three public repos get without Palantir. All quoted pages were captured on September 29, 2026, and pages change.

Six Sources Use Ontology, Semantic Layer and Knowledge Graph in Overlapping Ways

Cube’s introduction page uses two of the three terms within a few lines. It calls Cube an agentic analytics platform “built on an open-source semantic layer,” and 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.”

The phrase knowledge graph appears once on that introduction page. The data-model page and the access-policies page, both read for this piece, do not use it at all.

dbt reaches for a graph word without the knowledge label. The semantic models page says: “Think of semantic models as nodes connected by entities in a semantic graph.” In that sentence, semantic models are the nodes and entities are the connections between them. The word ontology does not appear on any of the six dbt pages read.

Microsoft’s Fabric IQ ontology page, which labels the item preview, goes the other direction. It says: “You can build an ontology from scratch, or you can generate it directly from semantic models.” It also places the ontology in the stack: “Ontology is the business context and semantic modeling layer between enterprise data and the experiences that consume it.”

Read together, those two sentences describe something named ontology, described as a layer, and producible from another product’s semantic model.

Palantir’s architecture page takes the opposite position on the label. It 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 of this series read that sentence as a boundary claim. Here the second clause matters: the sentence objects to a thin semantic layer.

The same architecture page then uses the word for the Ontology’s own contents: “The Language models the semantic objects, links, and properties; along with the kinetic actions and automations”. The why-ontology page adds: “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’s objection targets a thin design that cannot carry four kinds of integration, while the word semantic appears in its own descriptions of the Ontology.

An article on the ServiceNow Community site, dated November 17, 2025, uses three of the terms in one piece. The snapshot does not show whether the account is official, so this piece describes it only as a community-site article. It calls a knowledge graph “a semantic overlay that helps AI understand how your business works” and, “in AI terminology,” calls the structure that defining a knowledge graph produces an ontology.

One section heading in that article is “How the Semantic Layer Works.” A later sentence lists what the knowledge graph does not do: “Knowledge Graph does not store new data, duplicate information, infer relationships, or bypass security.” So a page that uses all three words also says the knowledge graph does not infer relationships.

C3 AI’s marketing page describes modeling the enterprise as a unified ontology graph. That is marketing wording, not technical documentation, and part 1 already quoted the original sentence.

The word itself is unevenly spread. The string “ontolog” appears nowhere in the six dbt, three Cube and eight Looker pages read, or on the Databricks, Snowflake and Microsoft semantic model pages, while the Fabric IQ and Palantir pages use it throughout.

Across these pages, the names alone do not sort the meanings. The table below sets out how each source describes itself, using only wording from the pages read.

In OWL 2, an Ontology Is a Formal Vocabulary That Reasoners Can Infer From

The OWL 2 Overview defines the word in one sentence: “Ontologies are 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 unit of definition is a term, and its meaning is fixed by formal semantics.

That is where the consuming side differs. 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: “These two semantics are used by reasoners and other tools”.

Inference is the core of the OWL 2 picture. Among the groups compared here, the W3C documents are the ones where derivation by formal semantics sits at the center of the definition.

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 fact missing from a database is “usually considered false (the so-called closed-world assumption),” while an OWL 2 document treats it as possibly missing, “following the open-world assumption.”

A second warning concerns names. “OWL does not make the assumption that different names are names for different individuals.” In practice, two different identifiers are not assumed to name two different things.

The third warning concerns validation. The Primer says OWL 2 is not a schema language for syntax conformance: “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.”

That sentence is about checking that data is syntactically complete.

Validation of data shape belongs to a different W3C standard. SHACL is described as “a language for validating RDF graphs against a set of conditions.” The graph itself is described in RDF 1.1 terms: “RDF graphs are sets of subject-predicate-object triples”.

SHACL touches inference only by option: “SHACL implementations MAY, but are not required to, support entailment regimes.” A shapes graph can use “sh:entailment to indicate what inferencing is required by a given shapes graph.” SHACL’s uses also extend past checking: “Such descriptions may be used for a variety of purposes beside validation, including user interface building, code generation and data integration.”

The Primer draws one more line that matters here: “note that a domain (or range) statement is not a constraint on the knowledge, but allows a reasoner to infer further knowledge”. A statement that looks like a schema rule is inference in OWL 2 and a constraint in SHACL. Those two sentences come from two different documents, and the pairing is this piece’s, not the W3C’s.

What about actions? The scope descriptions in the W3C pages read center on vocabularies, graph data and validation. The pages read do not describe taking actions against outside systems.

SHACL, RDF 1.1 and the OWL 2 Overview were read only in part, so this row describes the pages read.

Semantic Layer Documentation Defines Metrics, Dimensions and Entities, Then Uses the Definitions to Compile Queries

The basic unit differs by product. dbt 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 “Applies to dbt v1.12 and later,” and its example YAML uses simple metrics, with a comment reading Simple metrics replace measures. On the pages read, the units are semantic models holding entities, dimensions and simple metrics, plus metrics as their own definitions.

Cube’s units are named on its introduction page: “Cubes represent business entities — customers, orders, line items.” A second sentence follows: “They define measures, dimensions, and joins between entities.” The page describes its own approach as follows: “Cube’s model is dataset-centric, expanding on dimensional modeling.”

Looker’s LookML page calls LookML the language for creating semantic data models, and the LookML row in the table below lists its units. The wording differs from page to page, but the shapes overlap: metrics or measures, dimensions, entities or cubes, and the joins or relationships that connect them.

The consuming side is where the documents give the most concrete answers. 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 dbt’s definitions through GraphQL and through a JDBC driver. The JDBC sentence reads: “Use a JDBC driver to query metrics and dimensions in downstream tools, while also providing standard metadata functionality.”

Cube describes a runtime 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 come in through a defined route: “AI agents like Claude, ChatGPT, or your own connect through the MCP server or Chat API to get analytics answers grounded in the same governed data model.”

Snowflake’s semantic views page also lists agents: “You can use Semantic Views in Cortex Agents and query these views in a SELECT statement.” The same page says: “Semantic views improve accuracy by combining LLM reasoning with rule-based definitions.” The word reasoning there refers to a language model’s reasoning.

That brings up a common shortcut, that the difference between camps is whether the consumer is an AI agent. The pages read do not support it, because Cube, Snowflake, Fabric IQ and Palantir all list agents among consumers.

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, as the Palantir section below shows. That is this piece’s reading; if other pages document consumers using definitions differently, this reading would have to change.

Three items in the same documentation push back on the summary above, and each is a different kind of thing. Each gets its own paragraphs.

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.” It adds a requirement for the other end: “The receiving server must be able to accept a JSON POST.” And it says where the parameter lives: “You can define an action for a dimension or measure.”

The page also says how success is judged. “A successful HTTP response will be considered a successful action.” A second sentence covers the response body: “Here success defaults to true and setting success to false will indicate in Looker that the request has failed.” The receiving server can also respond with validation errors for form parameters.

So the definition is written in terms of the outgoing request and the receiving server’s answer. The pages read describe an action hub as a separate route: “Actions that are served through an action hub server differ from data actions, which are defined by the action LookML parameter.”

A Looker best-practices page covers write-back to a data warehouse, and it is easy to misread. It states: “Through its Action API, Looker supports this use case for any data warehouse or destination.” Then it narrows the scope: “This documentation page walks customers who use Google Cloud infrastructure through deploying a solution on Cloud Run functions to write back to BigQuery.”

The page’s own code is called a demo action. Its design derives current-state tables from an append-only log at query time, which simulates updates, and its handler checks a secret token before accepting a request. Those are that demo’s design choices, not built-in Looker features and not Looker rules.

The Looker data-action, action-hub and write-back pages read do not discuss transactions, rollback, idempotency or action auditing on Looker’s side. An audit-log page was not captured. One sentence in the testing section of the action hub page mentions history: the status of a test action appears in the Scheduler History in the Admin panel.

dbt exports write a table inside the same data platform

dbt exports are a different item. 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.” A second sentence says where the write lands: “It directly executes a ‘create table’ statement so the data stays within your data platform.”

The page lists dbt version 1.7 or newer among its prerequisites. It also answers a question about lineage: “No, you won’t be able to reference an export using ref. Exports are treated as leaf nodes in your DAG.” Exports end the chain.

Exports write query results inside the platform that already holds the data. A Looker data action sends a request to a receiving server.

The dbt GraphQL, JDBC and SDK subpages and the permission-detail pages were not captured, so the pages read say nothing about dbt writing to outside systems.

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

Cube’s introduction describes its semantic layer this way: “The semantic layer is built on four pillars: data modeling, access control, caching, and APIs.” The knowledge graph sentence sits under the data modeling pillar. The units under it remain cubes and views, containing measures, dimensions and joins.

The access pillar is stated in the same tone: “Access control runs at the semantic layer, so the same policies apply to every consumer: AI agents, BI tools, embedded applications.” The knowledge graph label does not recur on that page.

The sentence after the label continues: “It defines metrics, entities, joins, and how they relate, upstream of any consumer.”

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 Defines Objects, Links and Action Types, Then Writes That a Thin Semantic Layer Cannot Do the Ontology’s Four-Way Integration

Palantir’s core-concepts page gives the basic unit in three sentences. “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.” Functions sit beside them, as covered in part 1.

The definition stays close to data. “An Ontology is a categorization of the world.” The page adds an analogy for the reader who knows tables: “You can think of each object type as analogous to a dataset”.

The overview page splits the contents into two kinds. It describes the Ontology as “containing both the semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security)”. The architecture page states the pairing as a rule: “semantics must be paired with kinetics”.

The overview also gives the self-description: “In many settings, the Ontology serves as a digital twin of the organization”. And it separates itself from neighbors: “Far beyond data cataloging or schema design solutions, the Ontology allows you to define a robust foundation for end-user workflows”.

The consuming side is developers and agents working with objects and actions. The OSDK page says: “The Ontology Software Development Kit (OSDK) allows you to access the full power of the Ontology directly from your development environment.” The why-ontology page says: “the decision-centric Ontology connects humans and agents directly to operations”.

Action is where Palantir’s answer differs most.

On the fourth question, the documents put the action in the definition itself. Part 2 of this series covered the transaction. 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 same page adds: “It also includes the side effect behaviors that occur with action submission.”

Side effects can reach outside: “This enables you to write to other source systems in your organization”. The webhooks page places two modes in a table. A writeback webhook runs before object changes and its failure is shown to the end user. A side effect webhook runs after object changes, and its failure is not shown to the end user; the table’s “Failure shown to end user?” column reads Yes for writeback and No for side effect.

For the writeback mode 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 then adds: “However, it is still possible that the external request may succeed but Ontology changes could fail.” It calls the arrangement “some degree of transactionality between Foundry and the external system.” Part 2 walked through the two modes.

This piece’s reading, which is a comparison of document structure and not of capability: Looker’s data action is defined by the request that goes out (label, URL, parameters, form), while a Palantir action type is defined by the changes it makes to Ontology objects, properties and links, with a notification or webhook optionally attached. If Looker documentation elsewhere defines explicit transaction semantics, this comparison would have to change.

The comparison is also a difference in how much each document discloses. Palantir wrote its own limits on external writes, and the Looker pages read do not discuss that question.

Permissions need two pages, with different audiences. The permissions page says: “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.” It also says: “This project-based permissions approach replaces the previous permission models: ontology roles and datasource-derived permissions.”

The core page still states: “Roles are the central permissioning model in the Ontology.” The permissions page’s replacement sentence applies to ontologies where the project-based capability is enabled. The pages read do not say 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 the terms OWL, RDF, SPARQL, triple, knowledge graph, inference, entailment, reasoner and SHACL.

The word reasoning does appear, in the sense of decision logic or model reasoning. One example is “the non-deterministic reasoning of LLMs”.

One further page, on interoperability, says: “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.”

The wording is “allows for.” The page says REST and JSON make synchronization possible. It does not say which formats are used, how fidelity is kept, or which mechanism does the work.

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

Fabric IQ’s Ontology, Still Labeled Preview, Is Generated From Semantic Models and Can Import OWL

Microsoft’s ontology page opens with a definition and a status line. “The ontology (preview) item in Microsoft Fabric IQ provides a shared, machine-understandable representation of your business.” The next line reads: “This feature is in preview.”

A June 2 blog post from Microsoft Build 2026 says ontologies are “expected to be generally available in the coming months,” while the ontology page still carries the preview label on the day it was captured.

The basic unit is defined in three sentences. “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.” In this piece’s reading, two of the three units, entity type and metric, resemble what the semantic layer family defines; the rule in natural language does not appear in the semantic layer definitions read.

The page ties the ontology to semantic models: “Ontology aligns with familiar semantic-model constructs while extending them with ontology-specific modeling concepts.”

On the consuming side, the ontology page describes a store of definitions. It says the ontology “isn’t itself a general-purpose data-query engine”. A second sentence describes the layer: “Ontology acts as a virtual semantic and context layer over these sources.” The next sentence says where the data stays: “Source data remains in the system that owns it, and consuming experiences can query the live bound source rather than copying all data into the ontology.”

A graph layer is optional. “Graph in Microsoft Fabric is an optional execution layer for scenarios in which the relationship path itself is important”. The page adds: “An ontology-derived schema graph doesn’t load instance data by default.”

The W3C connection is explicit in one sentence: “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 ontology page does not use the words inference, reasoner or entailment.

The word reasoning appears once, where a rule is made available to consumers during reasoning.

Two documents can be set side by side. Fabric IQ’s page says it imports RDF, Turtle and OWL and exports RDF and Turtle. Palantir’s export page describes its own JSON schema and warns against depending on it.

Actions are where the three Fabric IQ pages need the most care. Each names a different subject and scope. The rules page says: “A business rule is a natural-language definition. Ontology doesn’t run the rule against data or execute actions.”

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

The Build blog post has a third subject: 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 rules page adds a migration note: “The new ontology experience doesn’t currently provide direct integration with Activator.” Permissions come in two layers. The page says: “Fabric workspace and item permissions control access to ontology items.” Access to bound data follows the source’s own security.

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”. dbt’s MetricFlow page says: “MetricFlow is developed and maintained by dbt Labs and works with the Apache Ossie format.” Ossie and OSI appear in two different documents, and the snapshots do not connect them.

This piece’s reading: these pages show that the concepts compared here have crossing points, since Fabric IQ generates ontologies from semantic models and imports OWL, dbt mentions an exchange format, and Snowflake wrote about exchange standards. The sample covers only these sources; if later documentation shows different exchange formats or scopes, this summary would have to change.

Four Questions Sort the Documents Into Three Groups, With Fabric IQ Beside the Semantic Layer Family

The table below answers the four questions and the permission check for each source. Blank means not stated on the pages read, which is not the same as the product cannot do it.

Three groups appear when the rows are read against the columns, and this piece marks them as its own reading. The first is OWL 2, where the unit is a term with formal meaning and the consumer is a reasoner. The second is Palantir, where the units include action types and functions, and applications and agents invoke actions.

The third is the semantic layer family. Its units are metrics, dimensions, entities and joins, and its consumer compiles queries. Fabric IQ’s ontology falls beside that group because its units include entity types and metrics, and its consumers query the sources themselves. If Fabric IQ documentation defines actions or inference as first-class types, this reading would have to change.

Fabric IQ’s page also carries things the semantic layer pages read do not: natural-language rules, RDF and OWL import, an optional graph layer, and namespaces.

The questions turn into a short habit. Ask what the basic unit is, and hear whether the answer is metrics and dimensions, object and action types, or classes and axioms. Ask what the consumer does with the definition. Compiling a query, invoking an action and running a reasoner are three different answers.

Ask whether anything is inferred, and in which sense. Reasoning can mean a reasoner working from axioms, a language model working from a prompt, or a decision logic written by a person. The Snowflake and Palantir pages read use the word in the last two senses, and Fabric IQ’s ontology page uses it once, around rules. Ask where actions live. In Palantir’s documents, the action type is part of the definition. In Looker, an action is a parameter on a field and the receiving server executes it. In dbt, an export writes a table inside the platform. On Fabric IQ’s rules page, the ontology does not execute.

Ask where permissions attach. The answers range from a group-scoped policy on a cube or view, to a model-file grant, to workspace and item permissions, to a project. Fabric IQ’s answer has two layers: permissions on the ontology item, then the source data’s own security.

The Same Word Names Different Things, and the Pages Will Change

The W3C’s caveat in the opening paragraph reads differently after the table. The word ontology, in the pages read, names a formal vocabulary that reasoners can infer from, a set of object, link and action types, and a semantic modeling layer. Semantic layer and knowledge graph move around in similar ways.

Pages change. All quotes were captured on September 29, 2026, the Fabric IQ ontology is labeled preview, and the Snowflake post is dated September 23, 2025. A page read a year from now may answer the same four questions differently.

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.