Configure your solution’s data foundation to build a knowledge graph
How-to Guides → The Four Pillars How-to → Data Foundation How-to → Unified Namespace How-to → Model Relations How-to
Wire typed graph relations between Tags using Reference members and StartValue, optionally enriched with the /Attr dual-shape pattern. The result is a UNS that doubles as a queryable knowledge graph — visualizable, AI-groundable, and round-trippable with industrial ontologies.
Version 10.1.5+
This is a step-by-step recipe. It assumes you already understand UserTypes, Tags, and the Asset Tree from the Unified Namespace How-to. For the concepts and column reference, see UNS UserTypes Reference, UNS Tags Reference, and Industrial Ontology Integration How-to. |
In a knowledge graph, nodes are entities and edges are typed relations between them. In FrameworX:
That's the whole mechanism. Steps 1 and 2 build the edge for the Pump → Tank example. Step 3 adds the optional |
The example
A two-equipment water-treatment line:
Plant1/Pump_P1 --(FeedsInto)--> Plant1/Tank_T1 |
Pump_P1 fills Tank_T1. Each tag carries live process variables. You will add a typed graph relation between them and, optionally, a /Attr sibling carrying static metadata. End state: a runnable solution and a Knowledge Graph that renders the relation visually.

Two UDTs. The interesting member is FeedsInto on PumpType: declared with Type = Reference, it becomes the graph edge.
PumpType
Member | Type | Parameters | StartValue | Notes |
|---|---|---|---|---|
Flow | Double | Live process value (m³/h) | ||
Status | Text | stopped | Initial state at startup | |
FeedsInto | Reference | TankType | Plant1/Tank_T1 | Typed pointer at the downstream Tank. See Step 2. |
TankType
Member | Type | StartValue | Notes |
|---|---|---|---|
Level | Double | Live process value (%) | |
Status | Text | idle | Initial state at startup |
Create both via Unified Namespace → UserTypes → New, then add the members in the grid.
For the canonical member-column definitions (every column, every constraint), see UNS UserTypes Reference.
A Reference UDT member needs two fields to declare a graph edge:
Field | Purpose | Example value |
|---|---|---|
Parameters | The target UserType — what kind of Tag this Reference is allowed to point at. |
|
StartValue | The target Tag path the Reference resolves to at runtime startup. |
|
In JSON form (for write_objects or copy-paste into a row):
{
"Name": "FeedsInto",
"Type": "Reference",
"Parameters": "TankType",
"StartValue": "Plant1/Tank_T1"
}
|
When the runtime starts, every PumpType instance gets its FeedsInto.Link resolved to Plant1/Tank_T1 automatically. The FrameworX object model now has a typed edge from Pump_P1 to Tank_T1.
A Reference points at the tag that carries the target entity's identity.
|
StartValue set on the UDT member is the default for every instance of that UserType — all PumpType tags point at the same target. To make one instance point somewhere else, set the Reference target on that specific tag using its target picker; the per-instance value overlays the type default for that instance only. Other instances still fall back to the UDT-level default. |
The /Attr dual-shape pattern stores static, design-sheet-style metadata on a sibling tag — separate from the live equipment tag. The naked tag carries dynamic process variables; the /Attr sibling carries literals like Manufacturer, ModelNumber, InstallationDate.
When to use which shape:
Use case | Pattern |
|---|---|
Plain process equipment, no descriptive metadata | Naked tag only |
Conceptual containers (Enterprise, Site, Area) — folders, not equipment |
|
Equipment + design-sheet metadata + ontology round-trip | Both (naked + |
For Pump_P1 to carry both live process data AND nameplate metadata, declare a second UDT:
PumpType_Attr
Member | Type | StartValue | Notes |
|---|---|---|---|
Manufacturer | Text | Grundfos | Static literal, never updated at runtime |
ModelNumber | Text | CR-32-4 | Static literal |
MaxFlowRate | Double | 50 | Design rating (m³/h) |
Then create a sibling Tag at Plant1/Pump_P1/Attr of type PumpType_Attr (see Step 4).
On RDF/OWL export the pieces map like this: each UserType becomes an OWL class; a Reference member becomes an owl:ObjectProperty (its Parameters type is the range); a scalar member (Double, Text, …) becomes an owl:DatatypeProperty; each Tag becomes a NamedIndividual. The ISA-95 / ISA-88 levels — Enterprise, Site, Area, Batch — are folders; the folder's |
For the full dual-shape rationale and the OWL/RDF round-trip semantics, see Industrial Ontology Integration How-to — sections "Two paradigms" and "FrameworX architecture and ontology alignment".
In Unified Namespace → Asset Tree, create the folder Plant1 and add three tags inside it:
Tag path | Type | Notes |
|---|---|---|
| PumpType | Live pump |
| PumpType_Attr | Optional — static nameplate metadata (Step 3) |
| TankType | Live tank |
Either:
Plant1 folder → New Tag, set the Type to the UDT, ORThe Asset Tree auto-creates the folder hierarchy from the slashes in the tag path.
Start the runtime (F5). With the configuration above, the FrameworX object model now exposes:
@Tag.Plant1/Pump_P1 <- PumpType instance (live) @Tag.Plant1/Pump_P1.Flow <- Double, live @Tag.Plant1/Pump_P1.Status <- Text, live @Tag.Plant1/Pump_P1.FeedsInto <- Reference -> Tank_T1 @Tag.Plant1/Pump_P1.FeedsInto.Link <- "Plant1/Tank_T1" @Tag.Plant1/Pump_P1/Attr <- PumpType_Attr instance (static, optional) @Tag.Plant1/Pump_P1/Attr.Manufacturer <- "Grundfos" @Tag.Plant1/Tank_T1 <- TankType instance (live) @Tag.Plant1/Tank_T1.Level <- Double, live @Tag.Plant1/Tank_T1.Status <- Text, live |
Quick sanity check from a Script or the runtime monitor:
// Read the resolved target through the Reference string target = @Tag.Plant1/Pump_P1.FeedsInto.Link; // Expected: "Plant1/Tank_T1" // Read a value of the target tag through the Reference double level = @Tag.Plant1/Pump_P1.FeedsInto.Value; // routed to Plant1/Tank_T1 |
For the full Reference-tag runtime semantics, see UNS Tags Reference → Reference Type.
SolutionSettings.KnowledgeGraphSource from the current UDT + Tag + relation state.Tag.UI.SelectedNodePath). The control writes the clicked node's full UNS path (dot notation, e.g. Plant1.Tank_T1) into that Tag.Tag.UI.SelectedNodeType). The control writes the clicked node's UserType name (e.g. TankType) into that Tag.The expected render for this example:
+----------+ FeedsInto +----------+ | Pump_P1 | -------------> | Tank_T1 | | PumpType | | TankType | +----------+ +----------+ |
For control configuration depth — render modes, source regenerators, HTML5 / OpenSilver parity, design-time preview semantics — see KnowledgeGraph Control Reference.
Once the UNS carries Reference edges (and, optionally, /Attr metadata siblings), the same three building blocks — Reference members, StartValue, dual-shape — unlock four capabilities:
/Attr suffix is stripped on export so OWL entity IRIs match the source ontology.SourceIri column providing the join key for diff and overlay.Reference member shows no value at runtime. Confirm Parameters is set to the target UserType name (case-sensitive), StartValue is the path of an existing Tag, and the target's UserType matches Parameters (or a subclass). The target must exist when the runtime starts; references to missing tags resolve to null.
Knowledge Graph control shows no edges. Click the Knowledge Graph button on the Asset Tree to regenerate KnowledgeGraphSource, or invoke TK.GenerateUnsVisual() from a Script. Edits to UDTs or Tags only refresh the source on the next regeneration; auto-refresh applies on subsequent renders.
Multiple PumpType instances all feed the same Tank. That is expected — UDT-level StartValue is the shared default. To point one instance elsewhere, set the Reference target on that specific tag; the per-instance value overlays the type default for that instance only. See UNS Asset Tree Reference → troubleshooting.
OWL round-trip drops the relation. If you used the ontology dual-shape, the Reference must target the identity-bearing node — the /Attr sibling. The exporter strips the /Attr suffix so the OWL IRI is clean. For plain equipment with no /Attr sibling, target the equipment tag itself. See Industrial Ontology Integration How-to.
Labels, SourceIri, Attributes).In this section...