Ontology (Factory Knowledge Graph)

Overview

The PlantPulse Ontology is a factory knowledge graph that represents plant entities and their relationships in graph form.

It helps the AI accurately process questions that can only be answered by following relationships, such as "Which sensors are connected to this equipment?" or "If this pump stops, what is affected?" When only a hierarchy is needed, an asset tree is sufficient, but a graph is required for impact propagation or multi-condition cross-referencing.

Built into the platform

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

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 Types)

These are the classes that appear in the RDF graph.

Class	Description
Site	Plant/Site
Area	Area (manufacturing building, utility, etc.)
Line	Production line
Equipment	Equipment (injector, packaging machine, etc.)
Asset	Common superclass for the above hierarchy nodes — used when querying assets regardless of hierarchy level
Tag	Sensor tag
AlarmConfig	Alarm configuration
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 Types)

Apart from the hierarchy, there are directional relationships between assets. Impact propagation questions follow these relationships.

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

---

Graph Tools (Integrated MCP)

The AI accesses the graph using the following three tools. Their names are similar, but they return different axes — distinguishing among the three is the key to this document.

Tool	What it returns	When to use
get_ontology	ISA-95 structure summary for one site + tree (area/line/equipment, tag count per equipment)	"How is this site structured?", "How many equipment items are there?"
query_ontology	Directional relationship graph (root + nodes[] + edges[])	"If X stops, what is affected?", "What feeds X?"
query_sparql	SPARQL SELECT/ASK result rows	Queries that need multiple conditions cross-referenced

If a pure hierarchy is all you need, get_asset_tree is more suitable than the ontology.

get_ontology Main Parameters

Parameter	Description
site_id	Required. If you only know the name, first resolve the ID with search_domains
asset_id	Root of the partial tree. Specify when viewing only a specific line/equipment
depth	Expansion depth below the root. Relative to the site root: 1=area, 2=line, 3=equipment
include_tags	If true is true, includes a list of tag names on equipment nodes. Default is count(tag_count) only

Trust only total_tag_count for the total tag count

Summing tag_count per node will be wrong. Tags in unexpanded branches are missing. If the response contains total_tag_count_unknown=true, it means they couldn't be counted. Don't estimate — narrow the scope and query again.

query_ontology Main Parameters

Parameter	Default	Description
entity_id	(Required)	Starting entity for traversal
direction	DOWN	DOWN=downstream impact, UP=upstream cause, BOTH
relation_type	(All)	FEEDS / DEPENDS_ON / PRODUCES
depth	2	Traversal depth 1~5

---

Impact Propagation Search Example

"If the injector DJ_M_01_1 stops, what is affected?" — follow downstream using direction=DOWN.

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

The response includes the visited nodes (nodes[]) and the traversed relationships (edges[]). If depth limit prevented further traversal, truncated is displayed. If this value is true, increase depth and query again.

---

Update Method

The graph is periodically rebuilt using the platform DB as its source. When you add equipment or change tags, it is reflected in the next update cycle, so recently registered equipment may not yet appear in the graph. The update cycle is set by the platform configuration semantic.graph.refresh.minutes.

---

Usage Scenarios

Scenario	How
Understand plant structure	get_ontology for area/line/equipment structure and tag counts at once
Trace anomaly causes	query_ontology direction=UP — search upstream of the abnormal equipment for cause candidates
Estimate impact scope of a stop	query_ontology direction=DOWN — find how far downstream impact spreads when stopped
Multi-condition cross-referencing	query_sparql — composite conditions such as "3-line equipment with tags that have alarms configured"