| Info |
|---|
New for 10.1.5 (draft preview). This section previews a feature shipping in FrameworX 10.1.5 (planned April 2026). The feature is not available in 10.1.4 or earlier. Content under review. |
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 → Compliance → Industrial Ontology
Version 10.1.5+
Industrial ontology integration in FrameworX is a layered stack of W3C Semantic Web standards, consumed and emitted by the built-in graph import/export engine. The engine reads an RDF graph, classifies each triple against a small set of supported predicates, and materializes the result into native Unified Namespace rows (UserTypes, Tags, AssetTree folders, UDT members). Round-trip is symmetric at the data-model level: the exporter walks the same UNS and emits an equivalent graph.
This section covers the standards actually implemented in 10.1.5, the policy templates that ship with the product, and the pages that show you how to use them.
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
Standard | Role in FrameworX | Status |
|---|---|---|
RDF 1.1 (W3C) | Core triple model. Every ontology artifact in the UNS traces back to an RDF triple. | Full |
RDF Schema (RDFS) (W3C) |
| Full |
OWL 2 (W3C) |
| Full (TBox subset) |
SKOS (W3C) |
| Full (label and definition subset) |
XSD datatypes 1.1 (W3C) | Literal datatype mapping for member definitions. | Full (common types) |
N-Triples (W3C) | Conceptual textual form of the UNS triple store. Every UserType, Tag, AssetTree folder, UDT member, and metadata value corresponds to one or more N-Triples of the form | Core (concept); textual emitter planned |
RDF/JSON ( | Default on-disk serialization for both import and export. Deterministic ordering, blank-node support, language tags, and typed literals round-trip cleanly. | Full (default file format) |
RDF/JSON ( | W3C RDF/JSON. Default round-trip format — the only format both the importer and exporter speak in 10.1.5. Deterministic ordering, blank-node support, language tags, and typed literals round-trip cleanly. | Full (import + export) |
JSON-LD 1.1 ( | Flattened form with top-level | Full (export only in 10.1.5; import via dotNetRDF in a follow-up release) |
Turtle ( | Prefix-abbreviated subject-grouped serialization with | Full (export only in 10.1.5; import via dotNetRDF in a follow-up release) |
N-Triples ( | One fully-expanded triple per line, no prefix abbreviation. The textual form that mirrors the UNS triple-store mental model. Most universally accepted; best for diff and audit. | Full (export only in 10.1.5; import via dotNetRDF in a follow-up release) |
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 is format-asymmetric in 10.1.5: RDF/JSON is the only parser. JSON-LD / Turtle / N-Triples readers are queued for a follow-up release backed by dotNetRDF. Practical implications:
Other standards that the ontology feature interacts with, or that are on the roadmap. These are documented here for context, not as first-class supported formats.
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..nt file form of N-Triples — planned for a future release . Not supported in 10.1.5 as on-disk formats. The file dialog currently lists these filters; picking a non-.rj file results in an error or a silent fallback to RDF/JSON output. Use .rj for reliable file-based on both import and export . (Note: this concerns the on-disk wire formats only — the N-Triples conceptual model of the UNS is always available; see above.)sides via dotNetRDF.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.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.
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.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 Industrial Local AI Ontology Demo uses this template end-to-end.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 triples are always present in the UNS configuration. In 10.1.5, MCP tools expose UNS content as JSON (structurally equivalent to the triples) and the graph engine serializes to RDF/JSON (.rj) on disk; a dedicated N-Triples textual emitter — both for MCP responses and for .nt files — is on the roadmap.
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:
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.owl:NamedIndividual becomes one Tag at path <containmentPath>/<entityName>/Attr. The /Attr convention is enforced on import and stripped on export so that OWL entity IRIs reflect identity, not storage layout.owl:ObjectProperty or owl:DatatypeProperty on a class becomes one member; on export, the original predicate IRI is restored from the SourceIri column.DisplayText, Labels, SourceIri, Description, and the Attributes JSON blob together hold everything a round-trip needs.INSERT DATA envelope details.| Children Display | ||||
|---|---|---|---|---|
|