Skip to main content
An ontology is a named model of the things your business talks about, their properties, and how they relate. Each part of the model is a definition. You edit definitions as drafts and publish them together as a release that agents read.

​
From warehouse to ontology

If you know your warehouse, you already know most of the model. This table maps the retail example’s tables onto Ontology terms. The left column stays where it is. The ontology says what each table means, and a Bindings says where each type lives.

​
Glossary

​
Ontology

The governance root for one model. It has an API name, an optional namespace IRI used to suggest identifiers, and a versioning policy: Any change allowed, Backward compatible (the default), or Fully compatible. Under the last two, a breaking change needs a new major version.

​
Object type

A kind of business thing. Its object kind is Entity (something that exists over time, such as Customer or Store) or Event (something that happened, such as Order). An object type holds its own properties, can implement interfaces, and can carry named constraints such as allowed values or a pattern.

​
Property

A named value on an object type, interface or link, such as customer_id or status. Each property has a data type: text, whole number, decimal, yes/no, date, date and time, duration, binary, reference, list, or group. A property can be Required, and one required single-value property can be the Identifier. A derived property declares how its value is computed from other properties; Ontology checks the rule but never evaluates it.

​
Shared property type

One data type reused by properties on several types, such as a lifecycle status. Each property that uses it must match its data type exactly.

​
Interface type

A set of required properties that several object types promise to have. An interface can extend up to 16 parent interfaces, 16 levels deep. An object type that implements it must declare every required property with the same data type. A named relationship between two types, readable in both directions. It has a source, a target, a cardinality on each end (exactly one, at most one, or many), and a reverse name. In the retail example, places reads “A Customer has many Orders · an Order has exactly one Customer”, and its reverse name is placed_by. A link can carry its own properties and a declared derivation rule.

​
Action type

An operation on one object type: the parameters it needs, the conditions under which it applies, and the properties it sets or clears. Action types are definitions only. Every action type is unbound, and nothing runs it.

​
Concept scheme and concept

Business terminology, following the W3C SKOS vocabulary. A concept scheme is a governed vocabulary with a canonical IRI and labels. A concept belongs to one scheme and has preferred, alternative and hidden labels in one or more languages, definitions, broader and related concepts, and mappings to concepts elsewhere. Concepts describe language; they do not replace object types or links.

​
Draft

The working version of a definition. You edit drafts freely. Once a release includes a draft version, saving it creates the next version, and the release keeps the version it has. Agents and tools never read drafts.

​
Release

A published snapshot of every definition in the ontology at one exact version, with a semantic version such as 1.0.0 and an ID of the form rel_…. A release never changes. Publishing a newer one makes it the current release; earlier releases stay readable by ID, and a withdrawn release stays in history but can’t be selected for new use.

​
Manifest digest

A SHA-256 checksum of a release’s contents, shown in Studio as the Release checksum. The same definition versions always produce the same digest. Every read re-checks a release against it, and context responses return it, so an agent can prove which model it used.

​
Binding

A published mapping from one exact ontology release to physical tables, columns, transformations and joins. See Bindings.

​
Record

A knowledge record is one governed business record, such as a return policy or a control. It is locked to an exact ontology release and object type version, holds values for that type’s properties, and has a business-valid period: Effective from and an optional Effective until. Its lifecycle is draft, active, superseded or retired. Records are for small, directly managed inventories, not warehouse-scale data. See Manage knowledge records.

​
Record set

A collection of knowledge records published together as one unchangeable release. Publishing freezes every non-draft record locked to the set’s ontology release at its current version. One record set release holds up to 50,000 records.

​
Rules that hold everywhere

  • Agents read releases only. Context, query plans, exports and record-set reads all name one exact release. They never mix in newer drafts.
  • References are exact. A release, binding or record pins the exact version and checksum of what it uses, so a later edit can’t change its meaning.
  • API names are stable. An API name uses lowercase letters, numbers and underscores, starts with a letter, and is at most 128 characters. Once a release includes a definition, Studio fixes its API name, and a rename counts as a breaking change.
  • Logical meaning only. Definitions reject table names, SQL, credentials and URLs. Physical detail belongs in a binding.