Ontology of Engineering Entities

• Ontology of Engineering Entities (OEE) is a machine-interpretable framework that formalizes engineering artifacts, standards, and design intents.
• It uses a modular architecture aligned with ISO IDO and domain-specific modules to support equipment classification, conformance, and CAD feature integration.
• The framework enables semantic reasoning and automated validation across document-linked design workflows using OWL, SHACL, and SWRL.

Searching arXiv for the cited papers and closely related terminology. arXiv search query: (Gjerver et al., 2 Oct 2025)

An Ontology of Engineering Entities (OEE) is a machine-interpretable conceptualization of engineering artifacts, specifications, standards, materials, operating conditions, geometric constraints, and document-linked design intents. In the material synthesized from "Machine-interpretable Engineering Design Standards for Valve Specification" (Gjerver et al., 2 Oct 2025), OEE is presented as an ontology architecture aligned with ISO DIS 23726-3 Industrial Data Ontology (IDO), intended to support semantic reasoning in equipment selection and quality assurance. In the material synthesized from "Towards Ontological Support for Principle Solutions in Mechanical Engineering" (Breitsprecher et al., 2013), OEE is not the paper’s native term; the paper instead develops a Federated Engineering Ontology (FEO), but it provides a directly relevant precedent for representing principle solutions, geometric constraints, and cross-document traceability. Taken together, these sources position OEE as a layered ontology framework in which engineering entities are described both as physical artifacts and as carriers of formalized requirements, conformance conditions, and design semantics.

1. Scope and architectural position

In the valve-specification synthesis, OEE covers engineering entities and artifacts including equipment and components, materials, environmental and operating conditions, standards and specifications, and functional location tags with process lines (Gjerver et al., 2 Oct 2025). The equipment scope explicitly includes valve categories and types such as Ball (floating, trunnion), Gate (wedge), Check, Plug, and Globe, together with feature-based variants such as long pattern, full bore, and three-way. The component scope includes Valve Body, Bonnet/Cover, Stem, Shaft, Closure Member, Seats, and End Connections. Piping features include flange face types such as RF, RTJ, and FF, connection types, and dimensional features from ASME B16.5 and ASME B16.10.

The same synthesis organizes OEE as a modular pyramid. Its top level is ISO DIS 23726-3 Industrial Data Ontology (IDO); domain-independent layers include SKOS and DCTERMS, with SSN and GeoSPARQL mentioned as helpful but not central; domain layers include valve-core, piping-core, materials-core, plus valve-collect, piping-collect, and materials-collect; standards-specialization modules are derived from API 6D, API 602, ASME B16.34, ASME B16.10, and ASTM material standards; and application/use-case modules include VDS-specific modules, plant instance models, and manufacturer product type models (Gjerver et al., 2 Oct 2025). The modules are described as exchangeable because they are stored in a W3C compliant format, and interoperable because they are aligned with IDO.

The principle-solution paper contributes a complementary architectural view. Its central artifact is a Federated Engineering Ontology integrating geometry, CAD features and assemblies, rules linking CAD features to geometry, and further federated modules for function, parts, physics, and STEP, all related within the heterogeneous DOL/Hets framework (Breitsprecher et al., 2013). OWL 2 DL is the primary logic for computable parts. This suggests that an OEE can be understood not only as a standards-centric ontology for specification and conformance, but also as a document- and geometry-aware ontology for reasoning across the full engineering design workflow.

A persistent architectural theme across the two sources is modularity. In the valve work, modularity is justified in terms of tractable reasoning, exchangeability, and maintainability; in the principle-solution work, federation is justified in terms of heterogeneity and cross-application semantic synchronization. A plausible implication is that OEE is best treated not as a monolithic ontology, but as a family of interlinked modules with explicit alignment layers.

2. Core entity system and upper-level alignment

The valve-oriented synthesis proposes an OEE core whose upper class is OEE:EngineeringEntity, with OEE:Equipment and OEE:Component as major subdivisions (Gjerver et al., 2 Oct 2025). Within equipment, OEE:Valve subsumes OEE:BallValve, OEE:GateValve, OEE:CheckValve, OEE:PlugValve, and OEE:GlobeValve. Within components, the proposed classes include OEE:ValveBody, OEE:ValveBonnetOrCover, OEE:ValveStem, OEE:ClosureMember, OEE:Seat, and OEE:EndConnection. Information-bearing entities include OEE:Specification, OEE:ValveSpecification, OEE:StandardSpecification, and OEE:Standard. Materials are represented by OEE:Material, OEE:ASTMGrade, and OEE:ASMEMaterialGroup. Environmental conditions are represented by OEE:EnvironmentalCondition, OEE:ProcessLineCondition, and OEE:Stream. Supporting value classes include OEE:PressureClass, OEE:NominalDiameter, OEE:FaceToFaceDimensionPattern, and OEE:EndFaceType.

The proposed alignments to IDO are explicit. IDO:hasAssembledPart is reused and specialized through OEE properties such as OEE:hasPart, OEE:hasValveBody, OEE:hasValveStem, and OEE:hasValveBonnetOrCover (Gjerver et al., 2 Oct 2025). lis14:containedBy and lis14:Stream from ISO 15926-14 RDL are also reused. Interoperability is further supported by an annotation-based provenance relation, OEE:isDefinedInEditionOfSpecification, which links classes to standard versions while avoiding logical inheritance from edition nodes.

The principle-solution synthesis offers a different, but compatible, entity system. Its formalized classes include PhysicalObject, NegativeShapedThing, Line, Intersection, LineAngle, Angle, Assembly, Part, 2D Sketch, FeatureConstructor, FeatureTransformer, Constraint, and AngleConstraint (Breitsprecher et al., 2013). In the alignment proposed there, FEO:Part ≡ OEE:Component/Part, FEO:Assembly ≡ OEE:Assembly, FEO:PhysicalObject ≈ OEE:EngineeringEntity, and FEO:AngleConstraint ⊑ OEE:Constraint. Additional entities present in the narrative include Function, FunctionalPart, Requirement, Material, Process, Interface/Connection, Bearing, Motor, Shaft, Drum, Brake, Cable, Sheave/Roller, Hook, and WorkingSpace.

The two sources differ in emphasis. The valve work centers on equipment, standards, and conformance. The principle-solution work centers on geometry, constraints, and traceability. Their combination yields a broad OEE view in which engineering entities include both physical artifacts and the design-semantic structures through which those artifacts are specified, constrained, and validated.

3. Formal semantics, axioms, and tabulated standards knowledge

In the valve-specification synthesis, textual standards are modeled as OWL classes and properties, while tabular data is captured as combinations of class expressions with data property restrictions (Gjerver et al., 2 Oct 2025). A central modeling pattern is the conversion of a table row into a class expression, for example pressure-temperature rows represented as conjunctions of restrictions such as working pressure less than or equal to a threshold and working temperature less than or equal to a threshold. Material group mappings are expressed as equivalence axioms in which an ASME material group is equivalent to a disjunction of ASTM-grade compliant object classes.

Representative axioms are given in both Manchester Syntax and Description Logic. For example, OEE:Valve SubClassOf OEE:hasValveBody exactly 1 OEE:ValveBody, OEE:Valve SubClassOf OEE:hasSpecification some OEE:ValveSpecification, and asme:MG_2_2_Valve ≡ OEE:Valve and (OEE:hasValveBody only asme:MG_2_2_Material) and (OEE:hasValveBonnetOrCover only asme:MG_2_2_Material) (Gjerver et al., 2 Oct 2025). Pressure-temperature allowance classes are then assembled compositionally, such as oee:WP_le_18_4_barg ≡ OEE:ObjectWithWorkingPressure and OEE:hasSpecifiedMaxDesignPressureBarg max 18.4 and asme:MG_2_2_CL150_StandardClass ≡ asme:MG_2_2_Valve and asme:CL150PressureRatedObject and ((oee:WP_le_18_4_barg and oee:WT_le_50_degC) or (oee:WP_le_16_2_barg and oee:WT_le_100_degC) or …).

The principle-solution synthesis contributes a second formalization idiom, centered on geometric intent. Its ontology uses reified entities such as Intersection and LineAngle, and expresses geometric laws through property chains (Breitsprecher et al., 2013). The core example is the rule that if lines $l_1$ and $l_2$ form the same angle with a third line $l_3$, then $l_1$ is parallel to $l_2$, stated as

$$\theta(l_1, l_3) = \theta(l_2, l_3) \Rightarrow parallel(l_1, l_2).$$

This is represented in OWL 2 DL by the property chain hasIntersection o hasLineAngle o lineAngleOf o intersectsWith ⊑ isParallelWith. A second property chain, hasAxis o isParallelWith o isAxisOf ⊑ isParallelWith, lifts parallelism from axes to parts.

These two idioms address different kinds of engineering semantics. The standards-centric idiom formalizes normative tables, edition-specific specifications, and material-class constraints. The geometry-centric idiom formalizes principle-solution intent and feature-to-geometry inference. A plausible implication is that an OEE capable of supporting both equipment qualification and design verification requires both data-range-heavy OWL patterns and relation-heavy geometric patterns.

4. Data properties, instances, and executable validation

The valve synthesis defines numeric data properties with unit suffixes in the property names, including OEE:hasSpecifiedMaxDesignPressureBarg, OEE:hasSpecifiedMinDesignPressureBarg, OEE:hasSpecifiedMaxDesignTemperatureDegC, OEE:hasSpecifiedMinDesignTemperatureDegC, and OEE:hasFaceToFaceDimensionMM (Gjerver et al., 2 Oct 2025). Units are implicit in the property names and can be annotated with PLM RDL unit-of-measure concepts. The same source explicitly notes that optional SHACL shapes can validate literal datatypes and value ranges, and that a translation layer may be introduced if OEE prefers QUDT or OM.

The instance-level pattern is also explicit. A functional location tag such as ex:P_63_CW032 is typed as oee:Valve and as a VDS class, and is associated with pressure, temperature, pressure class, nominal diameter, end face type, and a served stream (Gjerver et al., 2 Oct 2025). Manufacturer product types are represented as individuals with design data such as class rating, end face, dimensions, and materials. The validation workflow proceeds in three steps: create instances, run reasoning and rules, and inspect outputs. The outputs include pass/fail on shape constraints, inferred classifications such as membership in asme:MG_2_2_CL150_StandardClass, conformance assertions, candidate product suggestions, and explanation trails.

The formalisms and engines are stated directly. OWL 2 DL reasoning with HermiT is used for classification and satisfiability; SHACL is used for completeness and shape validation; SWRL is optional for explicit conformance and trace assertions; Pellet or Owlready2 are viable alternatives, although the paper used HermiT and SHACL (Gjerver et al., 2 Oct 2025). Example SWRL rules are given for asserting conformance to ASME B16.34, for identifying a manufacturer product type as a candidate for a VDS when end face, pressure class, and nominal diameter match, and for direct numeric compliance against allowed pressure and temperature values.

The principle-solution workflow is structurally analogous. Requirements extracted from the principle solution are represented as a requirements ABox $T_R$, while design facts extracted from the CAD model are represented as a model ABox $T_M$ (Breitsprecher et al., 2013). The verification task is then an entailment check, $T_M \models T_R$, performed with Pellet via Hets/DOL. This allows qualitative constraints to be verified even when they are only indirectly present in the CAD model. The canonical example is the inference that crane legs are parallel because each leg axis is perpendicular to the frame base axis.

5. Document semantics, traceability, and engineering workflow integration

The principle-solution paper is especially important for understanding OEE as a document-linked semantic system rather than only a standards ontology. It situates the principle solution at VDI 2221 step S4 and treats it as the analogue of a design specification in software engineering: it fixes the way the final product works without committing to a fully concrete shape (Breitsprecher et al., 2013). Principle solutions are represented as abstract sketches, hand-drawn or produced with simple graphics tools or CAD, often with natural-language explanation and standard graphical symbolism such as a folded arrow for weldment and crosses for bolts.

The semantic annotation process uses a “semantic illustration mapping” that links document fragments or image regions to ontology concepts and individuals (Breitsprecher et al., 2013). AKTiveMedia is used to make assertions regarding individuals explicit in the S4 document. Functional parts in the sketch are assigned names such as leg1 and leg2, which become individual IRIs for ABox assertions. Cross-document traceability is handled through refinement relations between VDI 2221 steps S1–S5. The synthesis gives the example that object S13 in the S4 sketch refines requirement S3 and is further refined into CAD objects S17 and S19.

The workflow is embedded in the Multi-Application Semantic Alliance Framework, identified as Sally/Theo/Alex (Breitsprecher et al., 2013). The background ontology serves as the synchronization point for services such as definition lookup, navigation, and verification. CAD-side extraction is handled by the “Alex for CAD” adapter, which exports constraints, parameters, and axes into the ontology-backed representation. This document-oriented architecture complements the valve workflow, where plant asset models, standard modules, and product type models are integrated under a shared ontology.

From an OEE perspective, the significance of this material is that it extends engineering ontologies beyond product catalogs and standards repositories. It shows how the same ontology can mediate between requirement lists, annotated sketches, CAD features, and downstream validation tasks.

6. Case studies, module coverage, and practical outcomes

The valve case study tests a valve selection and validation process using VDS inputs, manufacturer product types, standards, and process line data (Gjerver et al., 2 Oct 2025). The concrete inputs include Equinor BCAS302R, described as Ball Valve, Floating, CL150, RF, DN80, and Aker BP AB-GTDD00J, described as Wedge Gate, CL600, RTJ, DN20. Manufacturer product types include O.M.S. SALERI S7100.SF as a candidate for BCAS302R and IKM Flux Fig.No L6RR104 as a candidate for AB-GTDD00J. The standards used are ASME B16.34, ASME B16.10, ASME B16.5, API 6D, API 602, and ASTM A182, A240, A312, A351, A358, and A376. Functional location tags and process line data include P-63-CW032 for Plant Air line AI-63-006-AS200.

The reported outcomes are specific. BCAS302R VDS suitable for P-63-CW032. O.M.S SALERI S7100 product meets BCAS302R VDS. Dafram BMAS302R DN80 fails (trunnion vs floating conflict; types disjoint). AB-GTDD00J VDS suitable for A-64GT0073; IKM Flux L6RR104 product meets VDS (Gjerver et al., 2 Oct 2025). These outcomes illustrate the use of type classification, material-group conformance, pressure-temperature allowance checking, and dimensional and end-face compatibility.

The same source also provides ontology coverage counts.

Module or subset	Coverage
valve-core	197 classes, 30 object properties, 17 individuals
ASME B16.5 feature (use-case subset)	72 classes, 260 axioms
piping-core (use-case subset)	131 classes, 1097 axioms

Further quantitative context is also given. The industrial version of the ASME B16.5 feature module is described as \>450 classes, \>5000 axioms, and the industrial piping-core as \>1400 classes, \>10000 axioms (Gjerver et al., 2 Oct 2025). ASME B16.34 is exemplified by Material Group 2.2 and CL150 A-Standard, with the method stated to be generalizable to all groups and classes via OTTR templates.

The principle-solution case study concerns an assembly crane with a winch unit (Breitsprecher et al., 2013). Its principle solution captures qualitative constraints such as legs parallel, vertical beam perpendicular to horizontal cantilever, motor outside the working space, guidance of cable via rollers, weldments versus bolts, and a locating/non-locating bearing arrangement. The reported automated check demonstrates that the requirement that the legs are parallel is entailed from the CAD-extracted constraints by reasoning. The authors state that similar violations, including non-parallel legs, insufficient weldment stiffness, and wrong bearing arrangement, can be addressed in the same framework. Quantitative metrics such as precision, recall, or performance are explicitly not reported.

7. Limitations, non-equivalences, and future directions

Several limitations are stated directly in the valve synthesis. Coverage is partial in the example, because ASME B16.34 Group 2.2 is shown rather than all groups and classes (Gjerver et al., 2 Oct 2025). Exceptions and notes in standards may require SHACL, SWRL, or custom rule engines beyond OWL DL. Numeric units are embedded in property names, so unit conversion semantics are not modeled, and migration to QUDT or OM requires a mapping layer. Some domain core modules are proprietary, and open equivalents are recommended. Evolving standards require ontology maintenance, versioning, and possible reclassification of instances.

The principle-solution synthesis has a different limitation profile. Its demonstrated verification focuses on qualitative geometric constraints, and ABox extraction from CAD is under development or enhancement (Breitsprecher et al., 2013). OWL is the logical core, but arithmetic reasoning is limited in pure OWL DL; the framework therefore anticipates extensions to first-order logic or rules such as SWRL, with higher reasoning complexity localized to the relevant modules. Functions, behaviors, materials, and processes are present in the narrative and federated scope but are not fully formalized in the core verification example.

A recurrent misconception would be to treat OEE as a single standardized ontology already established across engineering domains. The cited material does not support that reading. In the 2025 valve paper, OEE appears as a proposed core and integration target aligned with IDO, with concrete modules and recommendations for incorporation (Gjerver et al., 2 Oct 2025). In the 2013 principle-solution paper, the operative ontology is FEO rather than OEE, and the mappings to OEE are explicitly presented as alignments rather than native terminology (Breitsprecher et al., 2013). Another misconception would be to assume broad standards interoperability out of the box: the valve synthesis states that mappings to IEC CDD and ECLASS are not provided, although adding mapping layers later is suggested.

The future directions are correspondingly pragmatic. The valve synthesis recommends adopting IDO as the upper ontology, reusing IDO:hasAssembledPart and lis14:Stream/containedBy, creating OEE standard modules for ASME B16.34, B16.10, API 6D, API 602, and ASTM materials using OTTR, providing a SHACL library for completeness and range checks, and building a rule and explanation layer with SWRL and annotations (Gjerver et al., 2 Oct 2025). The principle-solution synthesis points toward deeper semanticization of CAD features, stronger support for quantitative constraints, and integration with earlier-stage function models such as SysML-based function modeling and Albers’ Contact-and-Channel Model (Breitsprecher et al., 2013). This suggests an OEE trajectory in which standards conformance, geometric verification, and cross-document engineering traceability converge within a single modular semantic infrastructure.