Ontology — Factory Knowledge Graph

Overview

PlantPulse Ontology is a factory knowledge graph that represents the plant's entities and their relationships as a graph.

It helps AI accurately handle questions that can only be answered by traversing relationships, such as "Which sensors are connected to this equipment?" or "If this pump stops, how far does the impact spread?" When you only need hierarchy, an asset tree is enough — but impact propagation and multi-condition cross-queries require a graph.

Built into the Platform

The ontology is not a separate service; it runs inside the PlantPulse Platform server-web. The graph is an Apache Jena–based in-memory RDF model, rebuilt periodically from the platform DB as its source. There is no separate graph DB to install or operate.

The former standalone service plantpulse-ontology (:8888) has been archived. The tool names from that era (ontology_get_stats, ontology_get_graph, etc.) no longer exist.

---

Node Types (11)

These are the classes that appear in the RDF graph.

Class	Description
Site	Plant/site
Area	Area (manufacturing building, utilities, etc.)
Line	Production line
Equipment	Equipment (fillers, packers, etc.)
Asset	Common superclass of the hierarchy nodes above — used to query all assets regardless of level
Tag	Sensor tag
AlarmConfig	Alarm setting
CommandDef	Equipment command definition
Statement	Equipment specification
Document	Equipment attachment document
RegistryEntry	UNS registry entry

Hierarchy relationship: Site → Area → Line → Equipment → Tag

---

Relationship Types (3)

Apart from hierarchy, assets are linked by directed relationships. Impact propagation questions follow these relationships.

Relationship	Meaning
FEEDS	A feeds B (upstream → downstream)
DEPENDS_ON	A depends on B
PRODUCES	A produces B

---

Graph Tools (Integrated MCP)

AI accesses the graph through the three tools below. Their names are similar, but they return different axes — distinguishing the three is the key point of this document.

Tool	What it returns	When to use it
get_ontology	ISA-95 structure summary + tree for one site (areas/lines/equipment, tag count per equipment)	"How is this site organized?", "How many pieces of equipment are there?"
query_ontology	Directed relationship graph (root + nodes[] + edges[])	"If X stops, how far does the impact reach?", "What feeds X?"
query_sparql	SPARQL SELECT/ASK result rows	Queries that need to cross multiple conditions

If you only need the pure hierarchy, get_asset_tree is a better fit than the ontology.

get_ontology Key Parameters

Parameter	Description
site_id	Required. When you only know the name, resolve the ID first with search_domains
asset_id	Root of the subtree. Specify it to view only a particular line/equipment
depth	Expansion depth below the root. From the site root, 1=areas, 2=lines, 3=equipment
include_tags	If true, equipment nodes carry the list of tag names. By default only the count (tag_count) is included

Trust only total_tag_count for the total tag count

Summing the per-node tag_count values gives a wrong result, because tags on unexpanded branches are omitted. If the response contains total_tag_count_unknown=true, it means the count could not be determined — do not estimate; narrow the scope and query again.

query_ontology Key Parameters

Parameter	Default	Description
entity_id	(required)	Entity where traversal starts
direction	DOWN	DOWN=downstream impact, UP=upstream cause, BOTH
relation_type	(all)	FEEDS / DEPENDS_ON / PRODUCES
depth	2	Traversal depth 1~5

---

Impact Propagation Traversal Example

"If filler DJ_M_01_1 stops, how far does the impact reach?" — follow downstream with direction=DOWN.

     [Equipment: DJ_M_01_1] ← 시작 노드
              │ FEEDS
       ┌──────┴──────┐
       ▼             ▼
 [Equipment:    [Equipment:
  건조기]         컨베이어]
       │ FEEDS
       ▼
 [Equipment: 포장기]

The response includes both the visited nodes (nodes[]) and the traversed relationships (edges[]). If traversal was cut short by the depth limit, truncated is shown; when this value is true, raise depth and query again.

---

Refresh Method

The graph is rebuilt periodically from the platform DB as its source. When you add equipment or change tags, the change is reflected at the next refresh cycle, so equipment you just registered may not yet appear in the graph. The refresh interval is set with the platform setting semantic.graph.refresh.minutes.

---

Usage Scenarios

Scenario	How
Understand plant composition	Use get_ontology to get the area/line/equipment structure and tag counts at once
Trace anomaly causes	query_ontology direction=UP — find candidate causes upstream of the abnormal equipment
Assess shutdown impact scope	query_ontology direction=DOWN — the scope that spreads downstream when it stops
Multi-condition cross-query	query_sparql — compound conditions such as "Line 3 equipment with tags that have alarms configured"