4. Combined Ontology

Ontology

The ontology captures the project-level design logic for a competitive nuclear facility tender. It integrates six interdependent subsystems inside one shared model:

  • Nuclear Containment Building
  • Historical Building
  • Green Roof System
  • Wooden Roof Truss System
  • Bridge
  • Pavement System

Figure O1

Purpose and scope

Purpose

  • Explain the design logic of the tender at a system-integration level
  • Make interdisciplinary coordination clearer (who affects what, and why)
  • Support scenario comparison using the same evaluation metrics and constraints

Scope
The ontology focuses on:

  • System boundaries and relationships
  • Global design parameters that influence multiple subsystems
  • Shared performance metrics for evaluation
  • Mandatory project constraints (requirements)

It explicitly does not implement:

  • Operational simulations
  • Material-level calculations
  • Optimization algorithms

Figure O2

Ontology structure

The ontology is organized around six core classes:

  • Project (the overall tender context)
  • System (abstract class for all subsystems)
  • DesignParameter (inputs that control design decisions)
  • PerformanceMetric (outputs used to evaluate quality)
  • Requirement (constraints that must be satisfied)
  • DesignVariant (alternative configurations)

Each subsystem (Bridge, Road, GreenRoof, etc.) is a subclass of System, with one corresponding system individual.

Figure O3

Project integration

A single project instance, centralizes the decision logic. It connects to:

  • All subsystem instances (via hasSubsystem)
  • Global performance metrics (via hasOutput)
  • Mandatory requirements (via mustSatisfy)
  • Design variants (via hasDesignVariant)

This setup keeps all reasoning anchored at the project level, so every design alternative is evaluated consistently.

Global design parameters

Three global parameters drive the main cross-system trade-offs:

  1. Reactor Radius
  • Controls containment size and structural volume
  • Strongly affects embodied CO₂ and total cost
  • Drives economic return through usable area/income logic
  1. Bridge Position
  • Determines the river-crossing alignment
  • Changes bridge length and approach road layout
  • Creates a bridge vs. road trade-off in cost and CO₂
  1. Green Roof Coverage
  • Influences roof loads and truss demand
  • Can trigger wall strengthening for the historical building
  • Affects embodied CO₂ through added structural work and materials

Figure O5

Performance metrics

Two global performance metrics are used to compare alternatives:

  • Total CO₂ Emissions (A1–A3): embodied carbon from material production across the integrated project
  • Return on Investment (ROI): rental income over 15 years divided by total construction costs

Because these metrics are attached at the project level, each variant is compared on the same basis.

Figure O6

Requirements

The ontology explicitly models the key project constraints:

  • Maximum total embodied CO₂: 2,070,000 kg
  • Minimum green roof coverage: 10%
  • Mandatory river crossing via a bridge
  • Functional connectivity between containment and historical building
  • Reuse and renovation of the historical building
  • Containment geometric constraints (fixed height + minimum radius range)

Dependencies

The ontology captures key conceptual dependencies to keep reasoning transparent, for example:

  • Higher green roof load → higher truss demand → possible wall strengthening
  • Larger containment size → increased logistics demands → affects road class + bridge load capacity
  • Bridge and road placement depend on the spatial logic between containment and the historical building

This is not “calculation,” it’s the map of cause-and-effect relationships that your Dynamo workflows and simulations can then quantify.

Design variants

Without design variants, you only have one frozen design.

With design variants, you can compare alternatives transparently.

In this ontology, each DesignVariant:

  • Uses the same systems
  • Must satisfy the same requirements
  • Is evaluated using the same performance metrics
  • But differs in one or more design parameter values

This makes “Variant 1 vs Variant 2” explicit and auditable, even if the numbers are generated in Dynamo.