Semantic Schema

This page describes the ontology-aligned contextualization schema used to support the behavioral monitoring framework implemented in this repository.

Purpose

The goal of the semantic schema is to make explicit the relationships between:

  • the physical structure of the monitored asset,

  • the functional role of its subsystems and components,

  • the observations collected from sensors and control signals,

  • the inferred operational states,

  • the behavioral sequences extracted from those states,

  • and the higher-level operating and working modes used for interpretation.

The schema is not intended as a complete ontology for industrial asset management or as a full ontology-driven reasoning system. Its role is more focused: to provide a lightweight and explicit contextualization layer that improves interpretability, traceability, and consistency across the analytical workflow.

Federated semantic basis

The schema is designed as a lightweight federation of existing semantic resources plus a domain-specific extension.

Reused vocabularies

The current conceptual basis is aligned with the following semantic resources:

  • SOSA / SSN

    Used for representing sensors, observations, observed properties, and features of interest.

  • OWL-Time

    Used for representing time instants, intervals, durations, and temporal ordering relations.

  • QUDT

    Used for representing quantity kinds and units associated with industrial measurements.

  • SAREF (optional alignment)

    Can be used where asset-, device-, or function-oriented concepts require a more explicit IoT/device interpretation.

These vocabularies are not necessarily imported in full in every implementation layer. Instead, they provide the conceptual and semantic anchors for the domain-specific schema.

Domain-specific extension

On top of the federated core, the repository defines a minimal domain extension to represent the behavioral monitoring concepts that are specific to the industrial asset use case.

Core classes

The following classes are central to the schema:

  • IndustrialAsset

    The monitored industrial asset as a whole.

  • Subsystem

    A structurally meaningful part of the asset, such as a pump group or a control-relevant section.

  • Component

    A concrete physical element within a subsystem.

  • StructuralAnchor

    A stable structural reference used to preserve traceability between monitored evidence and asset interpretation.

  • FunctionalRole

    A process-oriented role associated with a subsystem or component.

  • OperationalState

    An elementary inferred operating condition derived from synchronized industrial observations.

  • BehavioralSequence

    An ordered temporal succession of operational states.

  • OperatingMode

    A higher-level category summarizing recurrent behavioral regimes linked mainly to internal process organization.

  • WorkingMode

    A higher-level category summarizing regimes influenced more strongly by external or contextual activation.

  • StatePrediction

    A predicted operational state derived from the data-driven identification layer.

  • AbnormalityEvidence

    Evidence indicating that a behavioral sequence or operating regime deviates from nominal behavior.

Core relations

The following relations structure the contextualization schema:

  • hasSubsystem

  • hasComponent

  • hasStructuralAnchor

  • hasFunctionalRole

  • derivedFromObservation

  • evidencesState

  • belongsToSequence

  • summarizedByMode

  • hasOperatingMode

  • hasWorkingMode

  • deviatesFromNominal

  • hasAnomalyScore

These relations are intended to preserve a traceable link between measured evidence, inferred behavior, and maintenance-relevant interpretation.

Three complementary views

The schema is organized around three complementary views of the monitored asset.

Structural view

The structural view describes what physically exists in the system.

Typical entities in this view include:

  • asset

  • subsystem

  • component

  • sensor

  • electrical channel

This view provides the stable anchors required to avoid reducing the monitoring representation to transient telemetry identifiers only.

Functional view

The functional view describes the intended role of the structural elements in the industrial process.

Typical examples include:

  • pumping

  • recirculation

  • dosing

  • standby

  • transition support

This view is important because the same component may contribute to different interpreted behaviors depending on the process stage.

Informational view

The informational view describes how the asset is observed and represented.

Typical entities include:

  • measurements

  • digital signals

  • observations

  • state predictions

  • behavioral sequences

  • operating and working modes

This view links raw monitored evidence to higher-level behavioral interpretation.

Repository alignment

The semantic schema is aligned with the three main modeling layers of the repository:

Model_A

Produces operational-state predictions from synchronized analog and digital signals.

Model_B

Extracts contiguous runs, active sequences, nominal sequence references, and anomaly-oriented comparison metrics.

Model_C

Interprets behavioral sequences through semantically contextualized operating and working modes.

In this sense, the semantic schema does not replace the analytical workflow. Rather, it provides a formalized contextual frame through which the outputs of Model_A and Model_B can be related to structural and functional interpretations in Model_C.

Conceptual flow

The semantic organization of the workflow can be summarized as follows:

  1. Observations are collected from sensors and control signals.

  2. Observations provide evidence for inferred operational states.

  3. Operational states are aggregated into behavioral sequences.

  4. Behavioral sequences are summarized into operating modes and working modes.

  5. Deviations from nominal sequences provide abnormality evidence.

This progressive mapping helps preserve the transition from raw observations to actionable operational knowledge.

Example conceptual mapping

A simplified conceptual interpretation might look as follows:

  • an electrical observation is linked to a monitored channel,

  • the channel is associated with a component or subsystem,

  • the observation contributes evidence for an inferred operational state,

  • the state belongs to a behavioral sequence,

  • the sequence is interpreted as an operating mode or working mode,

  • an anomalous change in sequence duration contributes abnormality evidence.

This type of mapping is the basis for contextual interpretation in the paper and in the repository outputs.

Implementation status

The current schema should be understood as a lightweight ontology-aligned contextualization scheme.

It already supports:

  • traceable conceptual alignment between structural, functional, and informational views,

  • explicit naming of the main behavioral entities and relations,

  • semantic interpretation of sequence-level outputs,

  • and future extensibility toward richer machine-interpretable assets.

At the same time, it remains limited in several respects:

  • it is not yet a full domain ontology for industrial asset management,

  • it does not yet implement a complete reasoning layer,

  • and some mappings remain heuristic or workflow-oriented rather than fully axiomatized.

This scope is intentional. The purpose of the current implementation is to make the contextualization layer explicit and reproducible without overcomplicating the monitoring framework.

Future extensions

Possible next steps include:

  • formal OWL/Turtle serialization of the schema,

  • SHACL constraints for validation,

  • SPARQL-based querying of contextualized behavioral outputs,

  • explicit linkage between paper tables/figures and semantic artifacts,

  • and richer integration with asset-management or digital-twin environments.

Summary

The semantic schema provides a lightweight but explicit formalization of the contextualization layer used in the industrial asset behavioral monitoring framework. It federates existing semantic resources for sensing, time, and quantities, and extends them with domain-specific concepts for operational states, behavioral sequences, operating modes, working modes, and abnormality evidence.

Its main purpose is to support interpretability, traceability, and future semantic extensibility across the repository and the associated research workflow.