BIMei Ontology
The formal model of the built-environment knowledge domain — its Concepts, Relations, Attributes and Knowledge Sets — and the canonical registry that publishes it.
What the BIMei Ontology is
The BIMei Ontology is the formal model of the built-environment knowledge domain, and the canonical registry that publishes it. It is the source of semantic truth for the BIMei ecosystem (AIO, RPF, MAD, LITE): objects are published as permanent, dereferenceable IRIs and consumed as a read-only, versioned snapshot — a registry of record, not a runtime hub.
This page explains the v4 model itself; the Help page covers how to use the registry (browsing, content negotiation, the snapshot, the MCP).
The Knowledge-Object model
v4 organises domain knowledge into four kinds of Knowledge Object, each with its own labelling convention:
| Concepts | nodes — what exists in the domain (PascalCase, e.g. Ability, Process). Browse → |
| Attributes | properties — generic, reusable qualities that attach to Concepts/Relations (camelCase, e.g. cost, status). Browse → |
| Relations | edges — the semantic links between Concepts (UPPER_SNAKE_CASE, e.g. HAS_PART, GOVERNS). Browse → |
| Knowledge Sets | compilations of Concepts, Attributes and Relations (KnowledgeFoundation / Block / Tool / Workflow / View). Browse → |
Concepts — what exists
The 20 Concepts are the mental constructs of the domain: Ability, Activity, Actor, Asset, Tool, Authority, Construct, Constraint, Content, Context, Decision, Deliverable, Event, Example, Process, Project, Responsibility, Role, Rule, System. They answer "what kinds of thing are there?" Some carry a controlled sub-type list drawn from a classification (e.g. Construct.type → ClassificationSystem, Taxonomy, Term…; Content.type → Container, Linkset…).
Relations — how things connect
The Relations are the canonical edge vocabulary: 35 canonical relations (HAS_PART, USES, PRODUCES, TRANSFORMS, DERIVES, GOVERNS, …) each refined by specialised sub-relations with an allowed domain → range (e.g. has_input: Activity → Content | Deliverable). This domain/range discipline is what lets the model validate statements and constrain retrieval.
An action verb that opens an Action Statement (e.g. assess, produce, govern) maps to a Relation (EVALUATES, PRODUCES, GOVERNS). The 50 regulated Actions are kept as their own vocabulary and mapped onto the Relations, so the two stay linked without being merged.
Knowledge Sets — and the Action Statement
The 5 Knowledge Sets are compilations: KnowledgeFoundation (dictionaries, classifications, taxonomies, models), KnowledgeBlock (self-contained items), KnowledgeTool, KnowledgeWorkflow and KnowledgeView. The KnowledgeBlock sub-types include the Action Statement — so the registry's atom is a v4 Knowledge Block.
An Action Statement is keyed by an action verb plus its object Terms, and is used three ways from one record — as Ability (typed by organisational scale), as Activity (typed by an Activity Type), and as Outcome (a targeted result). It is the smallest unit that still carries practical meaning (granularity level "Atom").
Key design choices in v4
A few deliberate stances balance ontological rigour with practical usability:
| <code>type</code> is controlled | The type attribute is restricted to sub-kinds of Concepts and Relations, and its values must come from a classification or taxonomy (itself a Construct) — never an ad-hoc list. |
| Authority ≠ Actor | Authority is a Concept in its own right — a power that is conferred and bounded by Context — not an attribute of an Actor. Separating the bearer of a right from the right itself supports attribute-based access control and auditable governance. |
| Context is first-class | Context (projects, scenarios, places) is an explicit Concept, so retrieval and reasoning can be constrained to a situation rather than relying on semantic similarity alone. |
| Topics & Projects are Constructs | BIMei Topics and Projects are taxonomies of Terms in the Construct layer (e.g. the Topic Taxonomy), not top-level Concepts — keeping the Concept list small. |
| Granularity reduces complexity | Knowledge is layered Atom → Cluster → Compound → Complex → System, so the same model serves a single term and a whole framework. |
What this registry publishes (and what it doesn't)
The registry is the canonical-truth core of the v4 model: it publishes the four Knowledge-Object vocabularies plus the regulated Actions, BIMd Terms, and the Action Statements built from them — each with a w3id IRI, consumable via the API and a read-only MCP.
It deliberately does not host the v4 execution machinery — the BPMN run-time, the Neo4j GraphRAG deployment, and the implementation-only edge types/properties. That layer is documented in the v4 source and remains future scope. Derived from BIMei Ontology v4.
Machines: /api/snapshot · JSON-LD @context · a read-only MCP server.
BIMe Initiative by CHANGE AGENTS AEC. Content licensed CC BY-NC-SA 4.0.