FrameworX consumes ontologies as RDF triples — the universal data shape behind every OWL/RDF graph, including the Industrial Ontology Foundry (IOF) suite. This page explains the triples concept and walks through importing IOF into a FrameworX solution.
How-to Guides → Standards Compliance How-to → Industrial Ontology Integration How-to → RDF Triples and IOF
Version 10.1.5+
A triple is the atomic unit of RDF (Resource Description Framework). Each triple states ONE fact in three parts:
Example triples about a single piece of equipment:
:Mixer_M101 rdf:type s88:Unit . :Mixer_M101 rdfs:label "High-Shear Mixer M-101" . :Mixer_M101 s88:capacityL "200"^^xsd:double . :Mixer_M101 s88:hasEquipmentModule :Heater_H101 . :Heater_H101 rdf:type s88:EquipmentModule . |
An entire ontology is just a (potentially huge) collection of triples. The 8-class ISA-88 ontology shipped with the LocalAI KnowledgeGraph Demo carries a few hundred triples; a real industry ontology like IOF carries hundreds of thousands.
FrameworX reads triples from three serialization formats — pick whichever your tooling produces:
.rj — RDF/JSON (W3C standard, JSON-encoded).nt — N-Triples (one triple per line, plain text).ttl — Turtle (compact, human-readable — the example above)The Unified Namespace itself is a triple store by construction — every UserType, Tag, AssetTree folder, and member corresponds to one or more RDF triples. See Industrial Ontology Integration How-to for the full architectural alignment.
The Industrial Ontology Foundry (IOF) publishes the de-facto industry-standard ontology suite for manufacturing — covering classes for Process, Material, Asset, Production, Maintenance, Quality, and Supply-Chain domains. IOF is built on the Basic Formal Ontology (BFO) upper-level framework and aligned with ISO 15926, ISA-95, and OAGIS standards. Home: industrialontologies.org.
Why care about IOF in a SCADA/HMI context? Customer assets modeled in IOF terms can flow into the FrameworX UNS as a typed Object Model, giving you:
export_graph_model.The IOF release is published as RDF/JSON (.rj) and other RDF formats — download from industrialontologies.org or use a customer-supplied excerpt.
IOF is a schema-only ontology (TBox) — it defines classes, properties, and axioms but ships zero equipment instances (ABox). The import workflow has two stages.
Run import_graph_model (Designer MCP) on the IOF .rj file with a schema-only policy:
import_graph_model(
source="file",
file_path="C:/.../IOF_OntologyPlusExampleTriples.rj",
policy="iof",
dry_run=true
)
# review the summary, then re-run with dry_run=false |
The importer creates one UserType (UDT) per IOF class. For the full IOF release, expect ~1,046 UserTypes. Curate via policy if you only need a subset (e.g., Process + Asset, skip Supply-Chain).
IOF carries no equipment instances; you author them with write_objects using the dual-shape pattern (see Industrial Ontology Integration How-to → Two paradigms):
<path>/<entity> — for each real-world piece of equipment, instantiate the IOF UDT (e.g., Plant/Reactor_R101 typed iof:Bioreactor), with dynamic members (Temperature, Pressure, Speed) wired to Devices, Scripts, or simulators./Attr envelope at <path>/<entity>/Attr — for static ontology-derived metadata about the entity (rdfs:label, manufacturer, design constants like Capacity_L). All /Attr members carry StartValue.The Local AI Ontology Demo shows this end-to-end on a small ISA-88 (not IOF) ontology — the same dual-shape pattern scales directly to IOF.
An IOF-grounded UNS is a SCADA solution that speaks the customer's industry vocabulary natively. Equipment that the customer references as iof:CentrifugalPump in their MES becomes a FrameworX UDT with the same name and the same IRI. Live process data flows on naked instances; ontology metadata flows on /Attr envelopes; both round-trip to external knowledge-graph systems.