Data pre-processing, analysis, and quality checks are constantly tailored to a specific data set. OntologyBased Data Access (OBDA) can provide the interoperability layer to apply the same procedure on heterogeneous data sets. The SOSA ontology, for example, provides a domain-independent generalization of sensor measurements, and is already employed in various OBDA applications. Data pre-processing procedures or visualization tools that operate on the SOSA structure can be generally applicable if the data is also structured following the ontology. We have developed a tool to show how to apply simple data analysis and visualizations using SPARQL queries generated real-time. The tool was initially centered around the horticultural domain, but in this demonstration we show how to generalize the technique across domains. The demonstration therefore contributes to the OBDA goals of enabling data quality verification and data analysis by presenting how to apply the same interoperability layer across domains.
It is a well-known problem that sensors expose their data in diferent formats and with various meanings. To tackle this problem and use their measurements for data analysis, the naming and formatting of the measured parameters need to be aligned with each other. A promising strategy for this problem is the definition and use of a common model or ontology that provides this alignment, usually called Ontology-Based Data Access (OBDA). The structure provided by an ontology can be used as a way of pre-processing the data for further analysis. Another part of this strategy is that of providing insight in the quality of the data in terms of, e.g., indicating incorrect values, missing values, unreasonable outliers, and time series misalignment.
In the horticultural domain, for example, many diferent competitors ofer sensors that measure temperature and humidity (T/Rv sensors) in a greenhouse. A T/Rv-sensor usually is small such that it can be easily positioned at a specific location to produce local measurements. In addition, it is cheap and therefore a large set of them can be placed to cover the entire greenhouse. Various other companies ofer climate computers that produce a wealth of measurements of diferent parameters inside the greenhouse, especially focused on indoor climate and outdoor weather conditions, but increasingly also around the status of the crop and energy usage.
The diferent formats inhibit data exchange, comparison, and analysis in various ways: • Comparing the climate computer data with the T/Rv measurements within a single greenhouse; • Comparing the T/Rv-measurements of sensors of diferent manufacturers; and • Comparing data of diferent climate computers by diferent vendors.
To realise the described strategy, we have been working on a Common Greenhouse
Ontology1 (CGO) [
The fields of Ontology-Based Data Access (OBDA) define an interoperability layer that utilises
an ontology for communication among a heterogeneous set of databases [
The Data Analysis Facility (DAF) is a tool intended to interpret data structured via the SOSA
ontology consisting of several components (fig. 1). The sensors provide data in a foreign format
which are transformed into RDF by mappers [
The diferentiating factor we want to demonstrate is that we built a domain-independent interoperability layer despite the domain-specific use case. This is made possible because the ontology strictly separates domain-independent SOSA concepts from domain-specific concepts added by the CGO (fig. 2). The DAF tool SPARQL queries can then retrieve domain- specific data through domain-independent queries. Our demonstration will consist of these two parts: the ontology design and the SPARQL queries instantiating the data visualizations.
The first component we demonstrate is the ontology model describing the structure of the data
available in the triples. The CGO extends the SOSA ontology by providing domain-specific
subclasses for, a.o., sosa:FeatureOfInterest (FoI) and sosa:ObservableProperty (OP).
As an example, we show how the CGO [
The main demonstration then follows on generalizing the CGO structure to other domains, such that the same architecture containing the same SPARQL queries can operate on data from multiple domains. First, we show how measurements in, e.g., industry or education can be represented analogously. A machine is the feature of interest that has its energy consumption (OP) observed. In the education domain the student is the feature of interest whose attendance rate (OP) is observed. This analogy shows that the ontology design structure is suficient to align a data set with the DAF; namely, a domain-specific extension (fig. 2) of the sosa:FeatureOfInterest, the sosa:ObservableProperty, and the sosa:Sensor. This description can be easily implemented by ontology developers. As an example we show this implementation for another domain, such as industry or education.
At this point in the demonstration we have shown that the DAF can be used across domains requiring for each application a domain-specific SOSA extension. The continued demonstration presents a software architecture based on semantic web protocols together with its implementation. Its main takeaway should be that the ontology described in the previous section enables writing of domain-independent SPARQL queries to retrieve domain-specific data.
As configuration, the DAF application needs one or more SPARQL endpoints that provide access to datasets using SOSA. Upon initialization of a dataset, the DAF issues domain-independent SPARQL queries to retrieve the domain-specific data (fig. 3):
2. Which properties of which features of interest do the sensors observe? PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX sosa: <http://www.w3.org/ns/sosa/> SELECT DISTINCT
?featureOfInterest ?featureOfInterestType ?label ?typeLabel WHERE { ?featureOfInterest rdf:type sosa:FeatureOfInterest . ?featureOfInterest rdf:type ?featureOfInterestType .
OPTIONAL { ?featureOfInterest rdfs:label ?label . }
OPTIONAL { ?featureOfInterestType rdfs:label ?typeLabel . } }
This domain-specific metadata is presented in the front-end to a user, who can select combinations of sensors and measurements (identified as the combination of a feature of interest and an observable property) that they want to use as model features in an analysis. We show that the SPARQL queries transferring data from the triple store to the DAF server are domainindependent.
For example, a user may select two model features: the temperature of the air in the greenhouse, as measured by sensor X, and the humidity of the air in the greenhouse, as measured by sensor Y. We demonstrate that a SPARQL query is generated on-the-fly based on the selected model features and sensors. The query result is a flattened view into the dataset with, in this example, three colums: the (normalized) observation time, the temperature, and the humidity of the greenhouse air.
We conclude the presentation by showing the data quality visualizations in the front-end: an
outlier detection analysis visualised through scatter plots and several boxplots. Because the
data is flattened, we can leverage the pandas [
Our demonstration will show a unified view of how to apply the SOSA ontology in sensor data application across domains. The ontology is already being applied in various use cases, but each time it is implemented diferently in another architecture despite the similar goal of automatically interpreting heterogenous data. Our work presents the initial version of an architecture that can be employed across use cases involving the SOSA ontology.
The demonstration additionally works towards increased functionality for OBDA systems.
Data quality and analytics powered by ontologies were identified by [