Lifting standards that are not ontologies, and what you must refuse to lift

When transforming industrial data models into OWL, engineers often encounter legacy formats that do not naturally map to semantic web standards. Two such formats are OPC UA NodeSets and ISA-95 B2MML XML Schemas. These formats are not ontologies, and their transformation into OWL requires careful attention to the nature of the data being modelled. The resulting lift must be inspectable and honest in its assumptions to be of value for downstream reasoning and integration.

Why Lifts Must Be First-Class Artifacts

Of the four pairs in the reference repository, two have no OWL on one side. ISA-95 ships with B2MML XML Schemas, while OPC UA ships with an address-space NodeSet. Any crosswalk between these formats must first perform a lift. The integrity of the crosswalk depends entirely on the honesty of this lift. If the lift is not explicitly visible and traceable, the crosswalk becomes a black box that may propagate errors or misrepresentations.

Therefore, the lift must be treated as a first-class artefact. This means documenting the decisions made, the transformations applied, and the limitations of the process. The honesty of the crosswalk cannot exceed the honesty of the transformation underneath it. The transformation must be verifiable and repeatable.

OPC UA NodeSet to OWL Mapping Rules

The OPC UA lift maps UAObjectType and UAVariableType to owl:Class. UAReferenceType becomes owl:ObjectProperty. The HasSubtype relationship translates to rdfs:subClassOf or subPropertyOf, depending on the role. InverseName relationships are modelled using owl:inverseOf to maintain symmetry in the property.

This lift is necessary to represent the hierarchical and relational structure of OPC UA in a way that is compatible with OWL. However, it deliberately excludes the instance layer. The NodeSet contains 912 UAObject, 3,369 UAVariable, and 462 UAMethod nodes. Lifting these into a TBox would distort the model by conflating instances with classes. This would inflate the class count and misrepresent the nature of the data.

B2MML to OWL Transformation

The B2MML lift translates xsd:complexType into owl:Class. The xsd:extension element becomes rdfs:subClassOf, reflecting the inheritance relationship. Elements within the schema become properties, with their domain and range defined accordingly. When maxOccurs=”1″, the property becomes a FunctionalProperty, indicating a one-to-one mapping.

This transformation ensures that the structural semantics of the B2MML schema are preserved in the OWL model. It allows for the use of reasoning tools and the integration of B2MML data into a semantic framework. However, it is important to resist the temptation to make assumptions beyond what the schema asserts.

Resisting the Temptation of xsd:choice

A common point of confusion arises from the interpretation of xsd:choice. This element does not translate to owl:disjointWith. A choice in XML defines that only one of the listed elements may appear at a given position in the document. It does not assert that the classes they represent are mutually exclusive in terms of instance membership.

For example, a lift that introduces disjointness would create axioms that contradict the original design of the schema. In this case, the transformation would have manufactured contradiction-capable axioms that ISA-95 never intended. The correct approach is to count what is skipped and report it. This ensures that no unintended semantics are introduced.

What to Take Away

Transformation from legacy formats to OWL is not a mechanical process. It requires a clear understanding of what is being modelled and what is being left out. The lift must be made explicit and inspectable. The temptation to make implicit assumptions must be resisted. Finally, the numbers and limitations of the lift must be recorded to maintain integrity in the resulting semantic model.

Reference

Apply it to your work