Ontology v2
15 concrete node types, 14 relationship types. PortCall-rooted, demand/decision/state separated, macro-level scope. The executable knowledge graph for centralized port optimization.
Design Principles
Five architectural axioms that define the v2 ontology. Every modeling decision flows from these constraints.
PortCall is Root
The optimization target is a specific terminal service episode, not the vessel itself. PortCall is the root entity, aligned with DCSA Port Call standard.
Demand / Decision / State
WorkPackage (what must be done), PlanItem (system's decisions), StateRecord (observed/predicted facts). Never conflate these three.
Mutable Facts as Records
ETA, berth availability, crane status, yard congestion — all time-varying facts live in StateRecord, not on edges. Supports versioning, confidence, provenance.
Macro-Level Scope
Only model at the resolution the optimizer needs. Containers, slots, lanes, routes are extension-pack material. MVP stays at block/zone/resource level.
Standard Reuse
OWL-Time for temporal, GeoSPARQL for spatial, SOSA/SSN for observations, PROV-O for provenance, SKOS for taxonomies.
Entity Relationship Explorer
Click any node to see its properties and connections. Click an edge for relationship details. Drag nodes to rearrange. Scroll to zoom.
15 Entity Types
Every physical, logical, and decision entity in port operations. Organized into four semantic categories.
Business / Optimization3 types
Vessel
Static vessel identity. Properties are stable physical characteristics that do not change per visit.
PortCall
The root optimization entity. A specific terminal service episode — the actual target of the global objective.
WorkPackage
A discrete unit of work demand. What must be done, separated from how (PlanItem) and what happened (StateRecord).
Location6 types
TerminalZone
Logical/operational zone within the terminal for zoning purposes.
MarineArea
Anchorage, channel, pilot boarding area. Fills the marine-side gap for pre-berth and post-service operations.
Quay
Physical rail/wall grouping of berths. Needed for STS rail group and berth adjacency context.
Berth
The vessel occupancy position. Core to pre-berth admission and service layer operations.
YardBlock
Yard storage operating unit at block level (not slot level in MVP). Basic yard organization unit.
Gate
External truck interface. Manages gate-side flow and congestion at the port boundary.
Resource4 types
STSCrane
Ship-to-Shore quay-side handling resource. Service time bottleneck.
YardCrane
Yard-side handling resource. Key to quay-to-yard absorption capacity.
TransportUnit
Unified AGV / internal truck / external truck transport resource.
MarineResource
Tug / pilot pool for admission and release operations.
Dynamic Overlay2 types
StateRecord
Time-varying observable facts: predictions, observations, actuals, congestion, availability. Mutable state externalized from edges into versioned records.
PlanItem
System decisions: reservations, assignments, sequencing, release. Optimizer output as first-class records supporting candidate/committed/actual lifecycle.
14 Edge Types
Edges define how entities relate to each other. Four semantic categories: structural topology, operational binding, decision/planning, and state/provenance.
Structural Topology10 types
Spatial containment hierarchy
Spatial containment hierarchy
Spatial containment hierarchy
Spatial containment hierarchy
Spatial adjacency/ordering
Spatial adjacency/ordering
Movement/access graph
Resource operating scope
Resource operating scope
Resource operating scope
Operational Binding6 types
Identity to episode
Work demand binding
State binding to episode
Decision binding to episode
Work start location
Work destination
Decision / Planning4 types
Demand-decision linkage
Resource assignment
Location reservation
Ordering constraints
State / Provenance2 types
What a record observes
Lineage/provenance
PortCall Lifecycle
A PortCall's lifecycle through the ontology graph, from vessel identification to post-service clearance.
PortCall created
Bound to PortCall
Track ETA, availability, congestion
Satisfy WorkPackages
STS, YC, Transport
Berth, YardBlock
StateRecords update, lineage tracked
Post-service clearance
Layer Mapping
How the ontology supports each of the three optimization layers. Every layer reads from StateRecord, writes to PlanItem, and acts on PortCall.
Pre-Berth Layer
- ETA forecast
- Berth availability
- Channel access
- Pilot/tug availability
- Berth admission
- Berth assignment
- Pilot/tug allocation
Service Layer
- Crane availability
- Projected service duration
- Yard load
- Transport congestion
- STS assignment
- Work sequencing
- Yard block assignment
- Transport dispatch
Post-Service Layer
- Work done actual
- Departure clearance
- Marine release availability
- Release plan
- Unberthing plan
- Departure slot
MVP Boundary
Intentionally excluded from MVP core. Each is a clean extension point for future ontology growth.