Ontology-Enabled Real-Time Analytics

• Ontology-enabled real-time analytics frameworks are semantic architectures that integrate heterogeneous static and streaming data using formal ontologies.
• They employ diverse architectural patterns—such as OBDA, virtual semantic access, and CEP—to enable continuous querying and context-aware decision support.
• Execution semantics leverage windowed processing, adaptive indexing, and query rewriting to meet low-latency and scalable real-time analytics requirements.

Ontology-enabled real-time analytics frameworks are semantic data and query architectures in which an ontology or knowledge graph provides the semantic backbone for integrating heterogeneous static repositories, high-velocity streams, and application-facing analytics. Across the literature, they are used to support ontology-mediated access, context-aware stream discovery, continuous querying, complex event processing, decision support, and cost-aware optimization in domains that include industrial diagnostics, smart manufacturing, software analytics, healthcare, high-performance computing telemetry, web data integration, and Industrial IoT (Kharlamov et al., 2016, Martínez-Fernández et al., 2018, Chandra et al., 27 Mar 2025, Sciarroni et al., 23 Feb 2026).

1. Semantic foundations and formal models

A central characteristic of these frameworks is that the semantic layer is not limited to taxonomic description. In analytics-aware OBDA, the ontology itself can expose aggregate concepts as first-class citizens. The Siemens-oriented framework defines an analytics-aware ontology language, denoted Oagg, whose vocabulary includes individuals $\Delta$, data values $D$, atomic roles $P \subseteq \Delta \times \Delta$, and attributes $F \subseteq \Delta \times D$, and whose aggregate concepts have the form $E = \circ r(\mathrm{agg}\ F)$ for a rational threshold $r$. Its semantics use a closed-world interpretation for attributes, and aggregate concepts are interpreted by applying the aggregate to the multiset of values associated with each individual. The same framework states that satisfiability of $O \cup A$ is checkable in polynomial time and that tractable conjunctive-query answering is obtained by reducing to aggregate-free safe ontologies (Kharlamov et al., 2016).

A second semantic pattern separates the problem domain from the solution domain. In smart manufacturing, the ontology distinguishes Problem, DataSource, and Insight from Solution, Task, Algorithm, Approach, Technique, and Metric. This separation allows the required transformation from data to insights to be modeled independently of the implementation sequence that realizes it. The paper also formalizes canonical time-series and evaluation objects as $x = [x_1, x_2, \ldots, x_T]$, $X = [x_1, x_2, \ldots, x_M]$, and $D = \{(X_1, Y_1), (X_2, Y_2), \ldots, (X_N, Y_N)\}$, and it defines $D$0 and $D$1. This framing makes label availability, output dimensionality, and task structure explicit semantic constraints rather than informal design choices (Farahani et al., 2023).

Unified ontologies for operational analytics follow the same principle of explicit semantics but emphasize harmonization across heterogeneous systems. In HPC operational data analytics, one unified ontology models telemetry from M100 and F-DATA within a single data model. The paper specifies 164 axioms in total, with 104 logical axioms and 60 declarations, organized around 12 classes including DataCenter, HPCSystem, Job, JobMetric, Rack, ComputeNode, Sensor, SensorReading, and Time. This design distinguishes sensor-centric telemetry from job-centric metrics and thereby makes cross-system comparison possible without conflating physical telemetry with workload-derived measurements (Khan et al., 8 Jul 2025).

Together, these models show that “ontology-enabled” in this context typically means more than semantic annotation. It means that aggregates, source descriptions, task graphs, capabilities, roles, and even deployment context can become part of the formal vocabulary on which analytics depends.

2. Architectural patterns

The literature presents several recurring architectural patterns. One is analytics-aware OBDA for mixed static and streaming data; another is virtual knowledge access over heterogeneous web or enterprise sources; a third is a stream-first pipeline in which CEP or Flink-style operators are coupled to a knowledge graph for discovery, authorization, or explanation.

Pattern	Representative systems	Distinguishing feature
Analytics-aware OBDA	Oagg + STARQL + ExaStream	Static and streaming sources unified through ontology, mappings, and continuous queries
Virtual semantic access	Ontop4theWeb; VKG-style OBDA	On-the-fly virtual RDF graphs without full materialization
Stream-first semantic analytics	OCEP; context-aware IIoT KG platform	Kafka/Flink or Kafka/Esper pipelines guided by RDF, SPARQL, and rules
Near-real-time enterprise integration	Q-Rapids / Quarry vision	Ontology-aligned ingestion, metric computation, and dynamic analytic view composition

In the Siemens architecture, applications submit STARQL queries; a translator rewrites the static conjunctive-query part using the ontology, unfolds static and streaming parts against mappings, normalizes HAVING into relational algebra, and dispatches the optimized query to a distributed stream engine that creates sliding window views, sequences timestamped assertions, joins static and streamed slices, pushes aggregates, and executes analytical functions (Kharlamov et al., 2016).

Ontop4theWeb follows a different architecture. It maps HTML tables and REST APIs into virtual relational schemas through source-specific virtual table operators such as WebTable, foursqr, and twitterapi, and then maps them to virtual RDF triples through R2RML or Ontop-style mappings. Query answering proceeds through ontology-based rewriting and mapping-based unfolding into extended SQL, with optional caching via a parameter $D$2 that controls freshness versus latency (Bereta et al., 2020).

Software analytics adopts yet another pattern. The implemented static approach uses Apache Kafka for ingestion, Elasticsearch indexes aligned to ontology classes for storage, periodic metric computation, and Kibana dashboards for low-latency quality views, whereas the dynamic approach is envisioned as a semi-automatic platform that starts from information requirements, identifies ontology concepts and paths, generates target schemas and data flows, and deploys them for immediate analytics (Martínez-Fernández et al., 2018).

Healthcare and Industrial IoT frameworks move semantic reasoning closer to runtime operations. OCEP uses Kafka for ingestion, Esper for CEP, HDFS for RDF persistence, and MapReduce SPARQL for semantic querying, yielding a Lambda-like split between speed and batch layers. The context-aware IIoT platform uses a domain KG, a stream-gathering KG, and a stream-transformation KG on top of Kafka and Flink, with JWT-based access control, SPARQL-driven stream discovery, and declarative pipeline orchestration (Chandra et al., 27 Mar 2025, Sciarroni et al., 23 Feb 2026).

3. Query languages, mappings, and reasoning

Ontology-enabled real-time analytics frameworks depend on a translation layer that turns semantic intent into executable stream or database operations. In STARQL, the output is a stream of timestamped RDF assertions. The language combines FROM STATIC ONTOLOGY ... DATA ..., FROM STREAM S [start,end] -> slide, USING PULSE, WHERE, SEQUENCE BY, and HAVING, and it supports indexed GRAPH i patterns, state comparisons, and analytical predicates such as PearsonCorrelation(?y,?z) > 0.75. Its windowing semantics are given explicitly as

$D$3

The same framework defines a rewrite–unfold pipeline in which ontology-based rewriting transforms the static conjunctive-query component into a UCQ, and mapping-based unfolding produces SQL and streaming queries that are sound and complete with respect to STARQL semantics (Kharlamov et al., 2016).

Mappings in these systems are not merely schema correspondences. They may express aggregate concepts, stream slicing, or compilation targets. For Oagg, an aggregate concept $D$4 is mapped through

$D$5

Streaming mappings compile GRAPH i constructs to queries over Slice(Msmt, i, r, sl, st), thereby exposing windows and sequencing as mapping-level concepts rather than purely procedural operators (Kharlamov et al., 2016).

Virtual knowledge access extends the same logic to non-relational web sources. Ontop4theWeb defines the virtual RDF graph induced by mappings as

$D$6

where $D$7 is a source-side query over extended SQL invoking virtual table operators. This allows standard SPARQL to be unfolded into extended SQL over APIs and HTML tables while preserving OWL 2 QL reasoning support (Bereta et al., 2020).

Reasoning is often rule-like rather than fully DL-centric at runtime. OCEP uses ontology-driven semantics primarily through RDF modeling, SPARQL filters, and CEP rules over medical thresholds. The context-aware IIoT platform materializes OWL and SWRL consequences ahead of time and uses runtime SPARQL to evaluate role-, site-, and collaboration-dependent access. Its formal accessibility relation is

$D$8

and it further states the implication

$D$9

This makes authorization part of the query semantics rather than an external post-filter (Chandra et al., 27 Mar 2025, Sciarroni et al., 23 Feb 2026).

A related line of work projects semantically typed RDF into property-graph structures to improve traversal-intensive analytics while retaining ontology-based validation. In the SPG model, reified RDF statements are mapped into labeled edges with property maps, and the resulting graph is checked against ontology types and data types. This suggests a division between an RDF ontology as the authoritative semantic layer and an LPG-style projection as the execution substrate for scalable graph analytics (Purohit et al., 2020).

4. Execution semantics, stream processing, and optimization

Real-time behavior in these frameworks depends on explicit execution semantics. The Siemens framework uses a real temporal dimension: window operators define bounded intervals, sequencing converts each window snapshot into an ordered sequence of datasets, and static WHERE patterns are joined into each state. It also states that handling of out-of-order or late arrivals is governed by the stream engine’s window implementation and that watermarks and allowed lateness are not part of STARQL’s formalism in that work (Kharlamov et al., 2016).

Optimization is correspondingly central. The same framework combines aggregate pushdown, static-before-stream filtering, adaptive indexing for stream joins, Materialized Window Signatures (MWS), and intra-query parallelism. Source-aware planning takes into account whether sources support GROUP BY/HAVING, window operators, or UDFs; whether MWS columns are available; and statistics such as arrival rates, window sizes, and candidate-set cardinalities. Cost-awareness is described through approximate objectives for latency, cost, and throughput, and plan selection favors MWS-based pruning, pushed-down aggregates, and distribution of heavy joins (Kharlamov et al., 2016).

CEP-oriented systems place temporal pattern evaluation in a dedicated engine. OCEP uses Esper over Kafka event streams, with threshold-based rules for conditions such as tachycardia and hypoxemia and with adaptive thresholds derived from simple moving average, weighted moving average, and exponentially weighted moving average. In the tuberculosis case study, Spark Streaming and Siddhi CEP are combined with a BFO-based ontology and SWRL rules; CEP emits signals such as CEP:FeverSpikeWithin7Days(?p), which the ontology layer can consume even though SWRL itself does not express temporal windows natively (Chandra et al., 27 Mar 2025, Chandra et al., 5 Oct 2025).

Industrial IoT platforms integrate event-time stream processing with semantic orchestration. The context-aware KG platform models stream operators as a DAG of sources, transformations, and sinks with explicit window classes such as Tumbling, Hopping, Session, and Count, and with parameters including windowDuration and windowHop. Flink jobs are generated from this declarative model, while SPARQL and SWRL determine which streams an agent may discover or process under a given role, location, and workflow context (Sciarroni et al., 23 Feb 2026).

A broader healthcare reference architecture reaches similar conclusions. It places Kafka or MQTT at ingestion, Spark Structured Streaming, Flink, or Storm at the stream-processing layer, OWL 2 EL or OWL 2 RL reasoning in the semantic layer, SHACL for constraint validation, and C-SPARQL or RSP-QL for continuous semantic queries. This suggests that low-latency ontology-enabled analytics usually emerge from composition of lightweight reasoning, windowed stream operators, and semantic metadata services rather than from monolithic online reasoning alone (Chandra et al., 7 Oct 2025).

5. Representative applications and reported results

The empirical record is heterogeneous because the frameworks target different execution layers, but the reported results show that semantic mediation is typically combined with explicit engineering for latency, storage, or operational feasibility.

Setting	Reported result	Observation
Siemens turbine diagnostics	Engineers must issue hundreds of queries over disparate schemas and sources, then stitch results, a process that consumes up to 80% of diagnostic time	Integration overhead is itself an analytics bottleneck
Siemens analytical optimization	For Pearson, overall time reduced by 8.18%, while the join with Measurements still dominated 69.58% of total time	Semantic optimization did not remove the dominant physical join
HPC telemetry KG	Storage overhead reduced by up to 38.84%, with an additional 26.82% reduction using blank nodes	Ontology modeling choices directly affected scalability
OCEP healthcare case study	Event detection accuracy of 85%	Semantic CEP improved healthcare event correlation
TB CEP + ontology + LLM pipeline	End-to-end latency about 4.2–4.7 s; simple SPARQL queries about 0.20–0.40 s; complex time-aware queries around 0.90 s	Real-time behavior was demonstrated at event and query levels
Context-aware IIoT platform	Common KG queries under 10 ms; monitoring service first response under 0.5 s; end-to-end source-to-Kafka latencies typically 25–34 ms	Context-aware semantic discovery coexisted with low operational latency

In the Siemens setting, the evaluation used a simulated turbine environment spanning 950 turbines and 100,000 thermocouple sensors, with archived streams stored in Measurements and windows tracked in Windows with MWS columns. For average-based and minimum-based similarity, MWS allowed the join to be eliminated entirely and HAVING to be evaluated against the Windows relation with indexes; for Pearson correlation, archived-window partitions could still be distributed across up to 16 worker nodes, and increasing archived windows by factor $P \subseteq \Delta \times \Delta$0 had an effect comparable to decreasing worker count by $P \subseteq \Delta \times \Delta$1 (Kharlamov et al., 2016).

In HPC telemetry, the unified ontology was evaluated on one day of M100 total_power data. The previous ontology required 25,375,684 triples and 1,074.89 MiB; the unified ontology required 16,917,120 triples and 657.36 MiB with URIs for SensorReading, or 481.00 MiB when SensorReading was represented as blank nodes. Even after these reductions, storage remained much larger than the NoSQL baseline, but the paper argues that the ontology enabled substantially more accessible querying and cross-system analysis (Khan et al., 8 Jul 2025).

Healthcare papers report both event-level and semantic-query evidence. OCEP reports 85% event-detection accuracy for illness monitoring and emergency responses over IoT sensor streams processed by Kafka, Esper, RDF, and HDFS-based SPARQL (Chandra et al., 27 Mar 2025). The tuberculosis framework reports CEP latency around 0.75–0.95 s, LLM latency around 2.3–2.7 s, GraphDB query latency around 1.0–1.3 s, and average end-to-end latency of approximately 4.44 s from a five-sample observation, alongside representative LLM query precision of about 0.72–0.82, recall of about 0.69–0.75, and F1 of about 0.73–0.78 (Chandra et al., 5 Oct 2025).

Industrial and enterprise platforms emphasize operational latency and manageability rather than purely predictive metrics. The context-aware IIoT platform reports that Q1, Q3, and Q5 KG queries remained under 10 ms across graph sizes up to 5,083,016 triples, while Q4 averaged about 1.44 s at the largest graph size; monitoring-service first response remained under 0.5 s, and query-service aggregations through Trino remained under 85 ms (Sciarroni et al., 23 Feb 2026). In software analytics, the implemented Q-Rapids stack is described as near real time rather than fully streaming, with Apache Kafka ingestion, Elasticsearch-backed storage, periodic metric computation, and Kibana dashboards for predefined quality views (Martínez-Fernández et al., 2018).

6. Limitations, misconceptions, and open directions

A common misconception is that adding an ontology is sufficient to make analytics real time. The surveyed systems do not support that claim. They couple semantic models with query rewriting, cost-aware planning, adaptive indexing, MWS precomputation, CEP engines, Kafka/Flink pipelines, or virtual access layers. This suggests that ontology enablement is a semantic control plane, not a substitute for execution engineering (Kharlamov et al., 2016, Sciarroni et al., 23 Feb 2026).

A second misconception is that ontology-enabled real-time analytics always requires full RDF materialization. Virtual graph approaches explicitly reject that assumption by constructing virtual RDF graphs on the fly from HTML tables and REST APIs, while OBDA and VKG architectures similarly keep data in native stores and translate SPARQL or ontology-mediated queries into source-level operations (Bereta et al., 2020). Conversely, storage-oriented KG approaches show that materialization can be costly: the HPC study still reports storage footprints roughly 238× or 174× the NoSQL baseline, depending on configuration (Khan et al., 8 Jul 2025).

A third misconception is that semantic interoperability implies complete standards alignment. The smart-manufacturing ontology captures data sources, acquisition metadata, tasks, approaches, and metrics, but it explicitly identifies standards for enforcing compatibility and interoperability as an open gap and future research need (Farahani et al., 2023). Healthcare reviews make the same point in a different vocabulary by emphasizing SHACL validation, provenance, access control, and policy ontologies as necessary governance layers rather than automatic consequences of using RDF or OWL (Chandra et al., 7 Oct 2025).

Formal coverage of stream semantics also remains uneven. STARQL provides explicit windowing and sequencing semantics, yet watermarks and allowed lateness are not formalized in the cited work (Kharlamov et al., 2016). OCEP performs true streaming at the CEP layer but relies on batch-style MapReduce SPARQL for semantic querying, which the paper itself notes is not suited to sub-second semantic reasoning on live streams (Chandra et al., 27 Mar 2025). The software-analytics dynamic approach is presented as an envisioned semi-automatic platform, and the paper states that a future case study is planned to validate the automation benefits (Martínez-Fernández et al., 2018).

Open directions recur across the literature. They include richer support for bag semantics and approximate analytics in OBDA; improved alignment between materialized views, indexes, and semantic metadata; lightweight but expressive handling of out-of-order streams; stronger treatment of uncertainty; automated mapping maintenance under schema evolution; formal validation of transformation pipelines; and integration of ML or LLM components without sacrificing explainability, provenance, or policy control (Kharlamov et al., 2016, Farahani et al., 2023, Chandra et al., 5 Oct 2025, Sciarroni et al., 23 Feb 2026).

Taken together, the literature portrays ontology-enabled real-time analytics frameworks not as a single software stack but as a design family. What unifies that family is the use of formal semantics to mediate heterogeneous sources, structure analytics tasks, and constrain execution, while stream engines, CEP, optimization, and storage strategies determine whether those semantics can be realized within operational latency bounds.