Introduction

Scenario: The command center needs a semantic layer so analysts can ask questions about suppliers, orders, shipments, and disruptions in business language.

Day 3 introduces the Foundry Ontology, the operational layer that sits on top of the data you integrated and connected on prior days and ties it to its real-world counterparts. For the command center, this is the day the raw supplier feeds, order tables, and shipment records stop being disconnected datasets and become a shared semantic layer that analysts can reason over in business language. The docs describe two halves of the Ontology: a semantic layer of object types, properties, and link types that names what exists in the supply chain, and a kinetic layer of action types and functions that lets people act on it later in the course.

Today you focus on the semantic layer because it is the foundation for everything the disruption-response problem requires. An object type is the schema definition of a real-world entity or event, an object is a single instance of that type, and an object set is a collection of those instances; together they mirror a dataset schema, a table row, and a filtered set of rows. Properties are the characteristics of each object type, analogous to columns in a dataset, and link types express how entities relate so an analyst can traverse from a delayed shipment back to the supplier and the orders at risk.

By the end of the day you will have modeled Suppliers, PurchaseOrders, Shipments, InventoryItems, and DisruptionEvents, wired the links between them, and validated that the model answers the questions the command center actually asks. This matters because a disruption is never a single dataset problem: answering 'which orders are exposed by this port closure?' requires the Ontology to connect events to shipments to orders to suppliers as one navigable graph rather than a pile of joins analysts must reinvent each time.

Capability focus: Object types, properties, link types, Ontology Manager · Artifact: Initial supply-chain Ontology model

Key concepts

Companion video

1. 1

   Create the Supplier and PurchaseOrder object types

   Open Ontology Manager and define two object types, each the schema definition of a real-world entity, then add the backing datasource that maps your integrated supplier and order data into objects. For Supplier, set a primary key such as supplierId and a title property like supplierName, and add properties (String for name/region, Geopoint for location, String or enum for risk tier) drawn from the dataset columns. For PurchaseOrder, configure a poId primary key and a meaningful title, and include properties such as orderDate (Date), quantity (Integer), and status, so the command center can reason about each order as a first-class entity.

   not startedinstance check

   Run check

   Confirms Supplier and PurchaseOrder object types exist with primary keys.

2. 2

   Create Shipment, InventoryItem, and DisruptionEvent

   Repeat the object-type creation pattern for the three remaining entities that complete the disruption picture, choosing property base types that match the data: Shipment with a shipmentId key plus Timestamp ETA/departure fields and a status String, InventoryItem with a sku key plus Integer on-hand quantity and a reorder threshold, and DisruptionEvent with an eventId key plus event type, a Timestamp, and a Geopoint or Geoshape describing the affected area. Each gets its own backing datasource so objects are populated from real records, and each needs a title property so analysts see human-readable labels in Object Explorer. Modeling DisruptionEvent as its own object type (not just a column) is what lets the command center treat a port closure or supplier shutdown as a queryable, linkable thing.

   not startedinstance check

   Run check

   Confirms the remaining three object types exist with primary keys.

3. 3

   Define link types between object types

   Create link types so the five object types form a navigable graph rather than isolated tables, choosing cardinality per the docs: one Supplier to many PurchaseOrders (one-to-many) and one PurchaseOrder to many Shipments, defined by a foreign-key property pointing to the other type's primary key. Use the guided helper to select the relationship type, pick the link resources, and name the link (API names are auto-generated). For a many-to-many relationship such as DisruptionEvent affecting many Shipments while a Shipment may hit several events, back the link with a join table datasource containing the key combinations, and link InventoryItem to Supplier so stock exposure traces back to its source.

   not startedinstance check

   Run check

   Confirms link types are defined so analysts can search around the model.

4. 4

   Validate the model against analyst questions

   Test the semantic layer by walking real command-center questions through it in Object Explorer: starting from a DisruptionEvent, can you traverse links to the affected Shipments, then to their PurchaseOrders and Suppliers, and reach the exposed InventoryItems? Confirm every object type has a working primary key and title, that property base types support the filters analysts need (date ranges on ETAs, geopoint proximity to a disruption zone), and that link cardinality matches reality so no relationships are dropped or duplicated. Where a question cannot be answered, fix the gap now - add a missing property or link - because this semantic model is the foundation the kinetic layer's actions and functions will build on later in the course.

   not startedself-attested

   Mark complete

   Self-attested: the model can answer three analyst questions from object pages.