Industrial Ontology Integration How-to

Bring RDF/OWL ontologies into FrameworX as UserTypes, Tags, and AssetTree folders; round-trip the full Unified Namespace back to a graph file for diff, archive, or upload to a triple store.

How-to Guides → Standards Compliance How-to → Industrial Ontology Integration How-to

Version 10.1.5+

Standards Supported

The following W3C standards have first-class implementations in 10.1.5. Every row is backed by real parsing or emitting code in the graph import/export engine, not by marketing claim. Predicates listed here are consumed by the importer and restored by the exporter on round-trip.

Importer / exporter format asymmetry (10.1.5)

The exporter ships all four W3C-standard RDF formats in 10.1.5 GA: RDF/JSON, JSON-LD 1.1, Turtle, and N-Triples. All four are pure-serialization writers sharing the same triple stream — choosing a format is purely a serialization decision; the exported RDF semantics are identical.

The importer in 10.1.5 reads RDF/JSON and N-Triples. JSON-LD and Turtle readers are queued for a follow-up release backed by dotNetRDF. Practical implications:

• Round-trip checks (export then re-import to verify) work with rj or nt end-to-end. Pick whichever you prefer — the underlying triple stream is the same.
• Publishing to a triple store works with any of the four formats — pick whichever your destination accepts.
• Sharing with an ontology team that wants Turtle or JSON-LD: export those directly. The receiving team can convert back to RDF/JSON or N-Triples via dotNetRDF, Apache Jena, or rdflib if they need to import into FrameworX before the JSON-LD / Turtle parsers ship.

Related and planned standards

Other standards that the ontology feature interacts with, or that are on the roadmap. These are documented here for context.

• Dublin Core Terms (dcterms:*, dc:*) — annotation predicates are round-tripped through the Attributes JSON column keyed as prefix:localName. No term-specific handling; every dcterms:* predicate is preserved uniformly as an opaque annotation.
• RDF/XML — planned for a future release on both import and export sides via dotNetRDF.
• SPARQL — the exporter can wrap its output in a SPARQL INSERT DATA {…} envelope for upload to a triple store. SELECT queries are the caller's job; the engine does not parse or evaluate SPARQL queries. Fetch query results through WebData and pass the response to the importer as inline content.
• SHACL, PROV-O, QUDT — not implemented. Shape validation, provenance tracking, and unit quantification are not performed by the import engine. If your source graph includes these vocabularies, their triples are either skipped or preserved as opaque annotations depending on predicate shape.

Policy templates shipped with the product

Two starter policy templates ship in 10.1.5 to simplify onboarding from well-known industrial vocabularies. Both are JSON configuration files consumed by the generic import engine — they set prefix mappings, module routing, typed-container predicates, and containment predicates, but do not introduce standard-specific code paths. Pick one as a starting point and edit the JSON to fit your ontology.

• IOF (Industrial Ontologies Foundry) — policy-iof.json. Real IOF IRIs: BFO_0000051 for containment, module routing for IOF_Core, IOF_Biopharma, IOF_SupplyChain, IOF_Construct, and the IOF_ prefix. Suitable as a starter for any IOF-derived ontology.
• ISA-88 (IEC 61512, batch control) — policy-isa88.json. s88: prefix, containment mappings (hasSite, hasArea, hasProcessCell, hasUnit, hasEquipmentModule), and a typeToUserType map covering the ISA-88 physical and procedural models. The Local AI Ontology Demo uses this template end-to-end.

Two paradigms: static ontology metadata vs. live equipment

A real-world ontology-driven UNS combines two complementary tag shapes. Understanding the split is the difference between an ontology shell and a working SCADA solution.

• STATIC ontology metadata uses the /Attr convention. A single tag at <path>/<entity>/Attr carries ontology-derived literals (rdfs:label, dcterms:identifier, manufacturer, classification strings). Every member has StartValue defined. The importer produces this shape for every typed OWL individual.
• LIVE EQUIPMENT uses naked UserType instances. A tag at <path>/<entity> (no /Attr suffix) typed by the equipment UDT carries dynamic members (Temperature, Speed, Status) fed by Devices, Scripts, or simulators. Live members typically carry no StartValue (the value arrives at runtime); a per-instance StartValue is acceptable only for genuine design constants (e.g. Capacity_L=200 on a specific Mixer_M101 instance). The importer does NOT produce this shape — author it with write_objects after the import.

Both shapes can coexist as siblings under the same auto-created folder. Access patterns:

• @Tag.Plant/CellA/Mixer_M101.Speed — live equipment member (dynamic)
• @Tag.Plant/CellA/Mixer_M101.Attr.Manufacturer — static ontology metadata member (literal)

Not every node has /Attr. Conceptual containers (Enterprise / Site / Area / Cell with only Name + Description literal members) typically use /Attr only. Containers with dynamic members (a Site with TotalThroughput, a ProcessCell with BatchProgress) use a naked UserType instance instead. The Local AI Ontology Demo demonstrates both patterns side-by-side on an ISA-88 pharmaceutical model.

FrameworX architecture and ontology alignment

The UNS is a triple store by construction. Every row in the Unified Namespace — every UserType, Tag, AssetTree folder, UDT member, and metadata value — corresponds to one or more RDF triples. N-Triples, the W3C line-based textual form of a triple (<subject> <predicate> <object> .), is the canonical way to describe and reason about that structure.

The Unified Namespace is the landing surface for imported ontology content. The mapping is intentionally small, so that graph files stay readable and round-trips stay symmetric:

• UserTypes hold class-level metadata. Every owl:Class becomes one row; rdfs:subClassOf sets BaseUserType; cycle detection prevents infinite loops; multi-parent OWL graphs pick the first named parent and duck-type the rest.
• Tags hold instance-level metadata. Every owl:NamedIndividual imports as one Tag at path <containmentPath>/<entityName>/Attr — the STATIC half of the dual-shape pattern (members carry StartValue literals from the source RDF). The /Attr convention is enforced on import and stripped on export so that OWL entity IRIs reflect identity, not storage layout. For nodes that ALSO carry live equipment data, a naked UserType-instance tag at <path>/<entityName> (no /Attr suffix) is authored alongside the /Attr envelope via write_objects — see the "Two paradigms" section above.
• AssetTree folders are materialized automatically from the slashed paths. The importer never writes folder rows directly.
• UDT members hold property-level metadata. Each owl:ObjectProperty or owl:DatatypeProperty on a class becomes one member; on export, the original predicate IRI is restored from the SourceIri column.
• Metadata columns preserve annotations. DisplayText, Labels, SourceIri, Description, and the Attributes JSON blob together hold everything a round-trip needs.

Related pages

• Import an OWL/RDF ontology into your UNS. Designer wizard and MCP reference for the import step, including the full OWL-to-FrameworX predicate mapping table.
• Export your UNS to RDF/OWL/GraphDB. Format selector, round-trip guarantees, and SPARQL INSERT DATA envelope details.
• Generate a visual report of your UNS. Relationship Graph button and Mermaid output reference.
• Local AI Ontology Demo. Reference solution shipping with 10.1.5 — a hand-authored ISA-88 mini-ontology that exercises every column in the 10.1.5 schema additions.

In this section...