# Ontology Driven Conceptualization of Context-Dependent Data Streams and Streaming Databases

Shreya Banerjee, Anirban Sarkar

► To cite this version:

Shreya Banerjee, Anirban Sarkar. Ontology Driven Conceptualization of Context-Dependent Data Streams and Streaming Databases. 16th IFIP International Conference on Computer Information Systems and Industrial Management (CISIM), Jun 2017, Bialystok, Poland. pp.240-252, 10.1007/978-3-319-59105-6_21. hal-01656254

HAL Id: hal-01656254

https://inria.hal.science/hal-01656254

Submitted on 5 Dec 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Ontology Driven Conceptualization of Context-dependent Data Streams and Streaming Databases

¹Shreya Banerjee, ²Anirban Sarkar

¹,²Department of Computer Applications, National Institute of Technology, Durgapur, India

¹shreya.banerjee85@gmail.com, ²sarkar.anirban@gmail.com

**Abstract.** Heterogeneous stream formats, related contexts, vocabularies and schema structures are key difficulties to facilitate sharing and extracting knowledge from stream databases. To resolve these heterogeneities, the key challenge is how to provide common semantic representation for context-dependent data stream formats along with streaming databases. To address such issues, this paper proposes an ontology driven formal semantics of context-dependent data streams together with a universal conceptualization of streaming databases. The novelty of this work is to handle heterogeneity, large volume and availability of streaming data, such as web content, commercial broadcasting data etc. It also facilitates to recognize evolving information from semantic representation of data streams at conceptual modelling level. Besides, the proposed conceptual model is flexible to represent finite partition of stream and thus help in data stream storing and further querying. The conceptualization is implemented using an ontology editorial tool Protégé for the initial validation of proposed set of formal semantics. Several crucial properties of the proposed conceptualization are specified in order to exhibit the benefits of the proposed work. The expressiveness of proposed model is illustrated using a suitable case study.

**Keywords:** Data Stream, Conceptual model, Context Modelling, Streaming Databases, Ontology

## 1 Introduction

In recent years, with the advancement of information and web technology, several applications need to work with continuous data generating processes. Those data are dynamic, time sensitive and continuous in nature. Data generated from Web-clicks, network monitoring, commercial broadcasting, sensor nets and stock quotes are few examples of such data [7]. These types of data are considered as a stream (data stream) rather than static snapshots [6]. Distinct *Data Stream Management Systems (DSMS)* are developed for processing and analysis of these data streams. Those DSMS are built due to limitations of traditional data management systems towards managing distinct data streams [2]. Hence, a well-organized model of data streams is the key requirement for proficient management of those data streams by DSMS. However, data streams have several exceptional characteristics, which make them difficult to model. *Firstly*, a data stream is usually defined as "an unbounded sequence of values continuously appended,
each of which carries a time stamp that typically indicates when it has been produced”
[6]. Secondly, in different applications these continuous data are represented in different
ways such as a discrete signal, an event log or a combination of trained series [15].
Thirdly, rapid changing of underlying contextual information of data streams generated
in diverse domains has serious consequences in deriving useful decisions from complex
real time applications [4]. Fourthly, distinct back-end databases ranging from strict
schema-based (for example Relational Databases) to flexible schema based (for ex-
ample NoSQL Databases) are used to store these data streams in structured, semi-
structured or unstructured way. Finally, a fixed or flexible finite partition, called win-
dow, are made from this continuous unbounded sequence while streams have to be
stored or retrieved from databases [11]. Hence, several challenges exist in efficient
modelling of data streams in order to facilitate sharing of information related to data
streams across different applications and DSMS. Starting with, how to represent com-
mon description of heterogeneous data streams semantically and syntactically. Sec-
ondly, how different surrounding contexts (contextual information) of data streams are
represented in a uniform way. Thirdly, how evolving contexts of data streams can be
recognized so that realization of dynamically added contextual information towards
data streams is achieved efficiently. To handle these issues, ontology will be beneficial.
The key reason for applying ontology is that it can establish consensus on unifying
conceptualization of heterogeneous data stream formats and related contexts. Ontology
is defined as a formal, explicit specification of shared conceptualization in terms of
concepts, relationships present between those concepts and related axioms [8].

Existing research works, primarily, focus on semantic representations of resources
and devices producing data streams. However, less attention is paid towards uniform
semantic representation of distinct context dependent data streams and further hetero-
geneous streaming databases. In [1, 3, 7, 15], authors have described abstract semantics
of streams. Authors in [7] have described an extensible framework that facilitates ex-
perimenting with different algorithms related with data stream mining tasks. In [2, 11],
authors have described powerful operator algebra for data streams. Both of these ap-
proaches have facilitated in supporting multiple query languages and data models. Se-
mantic Sensor Network (SSN) ontology [5] represents a high-level general schema of
sensor systems. IoT-A and IoT.est [12] provide architectural base for utilization and
representation of domain knowledge in sensor networks with some services and test
concepts. The Observation & Measurement (O&M) description of sensory Data are
described as a part of Sensor Web Enablement (SWE) standards from the Open Geo-
spatial Consortium (OGC) [9]. However, this description is based on XML (Extensible
Markup Language) which has weak semantic structure for expressing and describing
stream data ontology in more detail. Through approaches regarding Semantic Sensor
Web (SSW), context information such as time, space is added with sensors. However,
these approaches are mostly specific to certain domain and thus are not in high-level
abstraction [13]. Besides, none of these approaches has explored the representation of
contextual information related to data streams and streaming databases.

To address aforementioned challenges regarding modelling of data streams, an effort
has been made in this paper to provide precise semantics towards data streams, related
contexts and streaming databases. For this purpose, an ontology driven conceptualiza-
tion of data streams along with its related context is devised. The novelties of the pro-
posed ontology driven conceptual model are many-folds. The proposed conceptualiza-
tion efficiently deals with generic semantics towards modelling of variety of data
streams, resources producing those data streams and streaming databases. It further fa-
cilitates in sharing and preserving strong interoperability in heterogeneous applications
and DSMS. Next, the proposed conceptualization aids in recognizing static and evolv-
ing contextual information related to data streams along with a set of distinct relation-
ships. This essence of context sensitivity approach helps in reducing search spaces dur-
ing the time of querying on data streams. Besides, the proposed conceptual model may
assist in future in the extraction of new knowledge from data streams since it is ontology
driven and hence based on Open World Assumption (OWA) [8]. Moreover, it has also
provided discreteness in continuous streaming by representing finite, indefinite, fixed
and flexible partition of data streams.

## 2 Proposed Ontology Driven Conceptual Model for Context-Dependent Data Streams

The proposed conceptual model formalizes a common set of constructs and relation-
ships for conceptualization of context-dependent data streams and streaming databases.
The proposed model comprises of three interrelated layers (*Collection*, *Family* and *Stream*) and their identifiable construct types. Besides, the constructs are related with
each other using different relationships. The proposed model is specified axiomatically
using both first order and higher order logic to represent semantics of data-stream con-
structs and their interrelationships. The key constructs and distinct relationships of the
proposed model are specified in Fig. 1. In this figure, *Collection*, *Family* and *Stream*
layers are represented using shapes of rectangle, rounded rectangle and oval respec-
tively. Details of the proposed model are specified in following sections.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Proposed Conceptual Model for Data-Streams</figcaption></figure>
*Explanation:* Here, *number_of_data_value()* is a predicate implying that a data-stream may be infinite; *data_value()* and *time stamp()* are predicates implying data values and their corresponding time stamps respectively; □ operator implies mandatory participation of the argument and *Union_of()* is a predicate implying the union of arguments. Axioms F4 and F6 formalize the *Primary* and *Auxiliary Context* respectively.

(a) *Primary Context:* This represents basic information about data stream. Basic information of data stream mandatorily includes the data value at a specific time. The data value and its related specific time collectively can be called as a *Frame*.

F4: $\forall x \exists v \exists t_1 \exists t_2 \exists t (PC(x) \leftrightarrow (\Box (data\_value(x, v) \land starting\_time(t1) \land ending\_time(t2) \land existence(x) \leftrightarrow (t1 \land t2 \land duration(t1, t2))) \land ((\neg existence(x) \land time(t)) \leftrightarrow (t \land (t < t1) \land (t > t2))))))$

F5: $\forall x \exists v \exists t (Frame(x) \leftrightarrow (\Box PC(data\_value(y) \land time\_stamp(t1))))$

*Explanation:* Here, *starting_time()* and *ending_time()* are predicates implying start time and end time of respective arguments. Further, predicate *existence()* implies the existence time duration of the argument.

(b) *Auxiliary Context:* This context provides additional information relevant for *Primary Context*. For example, let assume humidity sensor generates data stream of humidity values. Then location may be an auxiliary context related to the primary context humidity. *Auxiliary Context* can be of several types as specified below.

F6: $\forall x \exists a_1 \exists a_2 \exists a_3 ((PC(x) \land AC(a_1) \land AC(a_2) \land AC(a_3)) \leftrightarrow ((pair(a_1, a_2, a_3)) \rightarrow x))$

*Explanation:* Here, *pair()* is a predicate implying the pairing of the respective *Auxiliary Contexts*.

(i) *Segment Context:* *Segment* represents a finite partition of the data-stream containing ordered sequences of *Primary Contexts* when the stream is to be going to store in a database. This size of partition may be fixed or flexible depending on the number of instances of a *Frame*. Axiom F5 formally represent *Frame*. Axioms related to *Segment Context* are specified below.

F7: $\forall x \exists y \exists z \exists m (Segment(x) \leftrightarrow (stream\_store((Union\_of((\Box Frame(y) \land Other\_AC(z)) \land (\Box Frame(m) \land Other\_AC(z)))) \land (t1 < t2) \land number\_of\_data\_value(finite))))))$

F8: $\forall x ((segment(x) \land size(x)) \leftrightarrow (number\_of\_instance&Dialysis))$

F9: $\forall x \exists y \exists l ((PC(x) \land segment(y) \land has\_auxiliary\_context(l)) \leftrightarrow l(x, y))$

*Explanation:* Here, *has_auxiliary_context()* has created a relationship instance *l* that has attached *Primary Context* with *Auxiliary Context*. Details of this relationship are stated in section 2.3. Besides, *size()* is a predicate implying the length of the *Segment*.

(ii) *Location Context:* This represents the current location/resources those holding the *Primary Context* with a specific time stamp. Assume, *L* is the set of locations. Related axioms are specified below.

F10: $\forall l((l \in Location) \leftrightarrow Q(L(Location)))$

*Explanation:* Here, *Q* is a predicate and *L(Location)* is a function returning locations of a *Primary Context*.

F11: $\forall x \exists y \exists t ((PC(x) \land location(y) \land has\_auxiliary\_context(l)) \leftrightarrow l(x, y))$

(iii) *Link Context:* This represents how the *Primary Contexts* are communicated over communication channel in terms of simplex, duplex etc. Besides, multiple segments of
similar or multiple data streams may be available in communication channel following some sequences. Hence, segment wise communications may be present within both of single stream and multiple data streams.

$$
\begin{align*}
\mathit{F12}: \quad & \forall x \exists y \exists z \exists l \exists k \exists m \exists n \Bigl( \mathit{Link}(x) \land \mathit{stream}(l) \land \mathit{stream}(k) \land \\
& \phantom{\forall x \exists y \exists z \exists l \exists k \exists m \exists n \Bigl(} l(\mathit{segment}(\mathit{PC}(y) \land \mathit{PC}(z))) \land k(\mathit{segment}(\mathit{PC}(m) \land \mathit{PC}(n))) \leftrightarrow \\
& \phantom{\forall x \exists y \exists z \exists l \exists k \exists m \exists n \Bigl(} ((\mathit{Communication_type-between})((\mathit{PC}(y) \land \mathit{PC}(z)) \lor ((\mathit{PC}(m) \land \mathit{PC}(n))) \lor \\
& \phantom{\forall x \exists y \exists z \exists l \exists k \exists m \exists n \Bigl(} (\mathit{communication_type-between})((\mathit{PC}(y) \lor \mathit{PC}(z)) \land (\mathit{PC}(m) \lor \mathit{PC}(n)))) \Bigr) \\
\mathit{F13}: \quad & \forall x \exists y \Bigl( \mathit{PC}(x) \land \mathit{Link}(y) \land \mathit{has_auxiliary_context}(l) \leftrightarrow l(x, y) \Bigr)
\end{align*}
$$

F13: $\forall x \exists y ((PC(x) \land Link(y) \land has_auxiliary_context(l)) \leftrightarrow l(x, y))$

Explanation: Here, *Communication_type Between* is a predicate implying the type of communication between *Segments* of single or multiple *Primary Contexts*.

These proposed *Auxiliary Contexts* are of minimal set. More distinct *Auxiliary Contexts* may be appended towards *Primary Contexts* based on design demand. Hence, proposed conceptualization realizes both static and evolving contextual information.

(c) *Finite Partition of Data Stream:* *Segment* has represented the finite partition of infinite data-streams for storing data-streams in database. Similarly, for the retrieval purpose another finite partition of data-streams can be defined as a *Window*. The size of *Window* may be fixed or flexible depending on numbers of instances of time stamps. Later, different data-stream query operators can be defined on this *Window*. The axiom of *Window* is as follows.

$$
\begin{align*}
\mathit{F14}: \quad & \forall x \exists y \exists z \exists m (\mathit{Window}(x) \leftrightarrow \\
& \phantom{\forall x \exists y \exists z \exists m (\mathit{Window}(x) \leftrightarrow } (\mathit{stream_retrieve})((\mathit{Union\_of})((\Box \mathit{Frame}(y) \land \mathit{Other\_AC}(z)) \land (\Box \mathit{Frame}(m) \land \\
& \phantom{\forall x \exists y \exists z \exists m (\mathit{Window}(x) \leftrightarrow } \mathit{Other\_AC}(z)))) \land (t1 < t2) \land \mathit{number\_of\_data\_value}(\mathit{finite}))
\end{align*}
$$

$$
\mathit{F15}: \forall x ((\mathit{window}(x) \land \mathit{size}(x)) \leftrightarrow (\mathit{number\_of\_instance}(\mathit{Frame}))
$$

2.3 Relationships in Proposed Conceptual Model

Distinct constructs of proposed conceptual model are interrelated. These relationships
can be of two types – *Inter layer* and *Intra layer* [14]. *Inter-layer relationships* can be
between dissimilar construct types of three different layers. *Intra-layer relationships*
can be between similar construct types of identical layer. Different relationships may
be present within a data stream, data stream and its related contextual information, and
in the layer hierarchy of streaming databases. These relationships may be *Containment*,
*Inverse Containment*, *Has_auxiliary_CONTEXT*, *Reverse_has_auxiliary_context*, *Se-
quence*, and *HasTime*. Former two are of *Inter-layer* and *Intra-layer* kind of relation-
ship and the rest all are of *Intra-layer* kind of relationship.

(a) Containment (Cnt): Containment relationships can be present between two con-
struct types when one encapsulates similar or different types of constructs.

$$
\begin{align*}
\mathit{F16}: \quad & \forall x (\mathit{Cnt}(x) \leftrightarrow \exists y \exists^n z (\mathit{Cmp}(y) \land \mathit{Cmp}(z) \land ((\mathit{sl}(y, z) \land \mathit{lev}(y) \land \mathit{lev}_{\mathit{Next}}(z)) \lor (\mathit{dl}(y, z) \land \mathit{layer}(y) \land \mathit{layer}_{\mathit{Next}}(z))) \land x(y, z) \land \neg(y = z) \land \\
& \phantom{\forall x (\mathit{Cnt}(x) \leftrightarrow \exists y \exists^n z (\mathit{Cmp}(y) \land \mathit{Cmp}(z) \land} (k(\mathit{range}(x) = z) \land (m(\mathit{domain}(x) = y) \land ((p(\mathit{value}(k) = 1) \lor \\
& \phantom{\forall x (\mathit{Cnt}(x) \leftrightarrow \exists y \exists^n z (\mathit{Cmp}(y) \land \mathit{Cmp}(z) \land} \mathit{greaterthan}(\mathit{value}(k), 1)))))
\end{align*}
$$

*Explanation:* Let, sl() is a predicate. Arguments of sl() are construct types (Cmp) and
express the fact that they are of similar type. In contrast, dl() is a predicate that takes
Cmp (construct types) as arguments and articulates that its arguments are in different
layers and are of dissimilar types. Besides, range() and domain() are functions returning
target and source domain of relationships respectively; *k* and *m* are predicates specifying those functions; *value()* is a function returning number of instances encapsulated; *greaterthan()* is a predicate implying whether the first argument is greater than second argument; *lev()* and *levNext()* are predicates implying whether arguments of these belongs to a level and its next lower level respectively; *layer()* and *layerNext()* are predicates implying whether arguments of these belongs to a layer or its next lower layer respectively; and *p* is a predicate.

(b) *Inverse Containment (ICnt)*: This relationship enables one construct type to encapsulate itself in order to encapsulate *Families* towards *Collections* dynamically.

F17: $\forall x(\mathit{ICnt}(x) \leftrightarrow \exists y \exists^n z(\mathit{Cmp}(y) \land \mathit{Cmp}(z) \land ((\mathit{FA}(y, z) \land \mathit{lev}(y) \land \mathit{lev}_{\mathit{Next}}(z)) \lor (\mathit{Col}(y) \land \mathit{FA}(z) \land \mathit{layer}(y) \land \mathit{layer}_{\mathit{Next}}(z))) \land x(z, y) \land \neg(y = z) \land (k(\mathit{range}(x) = y) \land (m(\mathit{domain}(x) = z) \land ((p(\mathit{value}(k) = 1) \lor \mathit{greaterthan}(\mathit{value}(k), 1)))))$

(c) *Has_auxiliary_CONTEXT (HAC)*: This relationship connects *Primary Context* with *Auxiliary Context*.

$$F18: \forall x \exists y \exists l ((PC(x) \land AC(y) \land HAC(l)) \leftrightarrow l(x, y))$$

(d) *Reverse_has_auxiliary_context (RHAC)*: This relationship may connect *Auxiliary Contexts* with *Primary Contexts* dynamically. This relationship is in reverse order of *Has_auxiliary_CONTEXT*.

$$F19: \forall x \exists y \exists l ((PC(x) \land AC(y) \land RHAC(l)) \leftrightarrow l(x, y))$$

(e) *Sequence (Seq)*: This is the relationship between two or more *Primary Contexts* when the data value of a particular time stamp is connected with the data value of the successive time stamp.

F20: $\forall x \exists f_1 \exists f_2 \exists f_3 \exists y_1 \exists y_2 \exists y_3 \exists l \exists t_1 \exists t_2 ((Frame(f_1, f_2, f_3) \land data\_value(y_1, y_2, y_3) \land time(t_1, t_2, t_3) \land f_1(y_1 \land t_1) \land f_2(y_2 \land t_2) \land f_3(y_3 \land t_3) \land Seq(l) \land (t_1 < t_2 < t_3)) \leftrightarrow (l(y_1, y_2, y_3) \land \neg(y_1 = y_2 = y_3) \land (((succeive\_order(y_1, y_2) \land succeive\_order(y_2, y_3)) \rightarrow succeive\_order(y_1, y_3)) \land ((succeive\_order(y_1, y_2) \rightarrow \neg(succeive\_order(y_2, y_1)))))$

*Explanation:* Here, *succeive_order()* is a predicate implying that the second argument is coming in next sequence of the first argument. Contrary, by reversing the order of arguments of the predicate *succeive_order()*, flow of the data stream can be realized in the reverse direction. In this way, dynamically appended data values towards data streams can be recognized.

(f) *Has Time (HT)*: This relationship represents the connection between data value and its existence time stamps. The axiom of this relationship is

$$F21: \exists i \exists j [HT(i) \leftrightarrow \exists t \exists x [(t \in Tm) \land data\_value(x) \land i(x, t)]$$

*Explanation:* Here, *Tm* is a set of timestamps.

The proposed conceptual model thus represents formal and universal vocabularies of context-dependent data streams and streaming databases. Using the axioms of stream layer, semantics of data stream and its associated heterogeneous context is specified. Likewise, through the entire layer hierarchy the proposed model is capable to represent common conceptualization of different streaming databases ranging from strict to flexible schema based. Thus, the proposed conceptualization deals with heterogeneity issue of data streams. Further, the proposed conceptual model is in high level abstraction.
Hence, representation of large volume of data streams can be managed using this proposed conceptualization efficiently in conceptual level. Besides, using *Has_auxiliary_CONTEXT* and *Inverse Containment* relationships dynamically added contextual information towards the domain have been recognized. In this way, the proposed conceptualization may facilitate in future in deriving new knowledge from data streams. Further, using *Sequence* relationship the rapid availability of data points towards data stream is realized. Furthermore, *Segment* and *Window* partition has facilitated in realizing discreteness among continuous stream. Moreover, the proposed conceptualization model is flexible as it provides flexible finite size towards data-streams using *Segment* and *Window*. It has also recognized the communication and available sequences between *Segments* or *Windows* of similar or multiple data-streams. Several other related crucial features are described in section 5.

## 3 Protégé Implementation of the Proposed Model

The proposed meta-model has been implemented in this section using OWL (Web Ontology Language) based ontology editorial tool Protégé [10]. Protégé facilitates representation of formally expressed axiom set of this proposed conceptualization towards OWL logic. It is composed of a number of reasoners for automated inference on ontological theory expressed in OWL logic. OWL is based on Description Logic.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Ontological graph of the proposed Conceptual Model using OntoGraf plug-in in Protégé</figcaption></figure>
<table><caption>Table 1. Mapping from Proposed Conceptual Model towards Protégé</caption><thead><tr><td>Constructs in Proposed Conceptualization</td><td>Corresponding Constructs in Protégé</td></tr></thead><tbody><tr><td>Collection</td><td>COLLECTION</td></tr><tr><td>Family</td><td>FAMILY</td></tr><tr><td>Stream Context</td><td>STREAM_CONTEXT</td></tr><tr><td>Primary Context</td><td>PRIMARY_CONTEXT</td></tr><tr><td>Auxiliary Context</td><td>AUXILIARY_CONTEXT</td></tr><tr><td>Segment Context</td><td>SEGMENT_CONTEXT</td></tr><tr><td>Link</td><td>LINK_CONTEXT</td></tr><tr><td>Location Context</td><td>LOCATION_CONTEXT</td></tr><tr><td>data_value</td><td>DATA_VALUE</td></tr><tr><td>timeStamp</td><td>TIME_STAMP</td></tr><tr><td>Containment</td><td>INTER_CONTAINMENT<br/>INTRA_CONTAINMENT</td></tr><tr><td>Inverse Containment</td><td>INTRA_INVERSE_CONTAINMET<br/>INTER_INVERSE_CONTAINMENT</td></tr><tr><td>Has_auxiliary_context</td><td>HAS_auxILIARY_CONTEXT</td></tr><tr><td>Reverse_has_auxiliary_context</td><td>REVERSE_HAS_auxILIARY_CONTEXT</td></tr><tr><td>Sequence</td><td>SEQUENCE</td></tr><tr><td>Has Time</td><td>HAS TIME</td></tr></tbody></table>

Three layers and their construct types have been mapped towards Protégé Classes. Besides, six key relationships of the proposed conceptualization are specified as Object Properties in Protégé. The mapping from the proposed conceptualization towards Protégé is specified in Table 1. Further, several Object Properties in the proposed conceptualization may have multiple sub object properties. Such as INTER_CONTAINMENT has sub property called INTER_CONTAINMENTilenage context has sub property called INTER_CONTAINMENT. Fig 2 describes the graph obtained through OntoGraf plug-in in Protégé.

## 4 Illustration of the Proposed Conceptual Model

Let, an application is aimed to determine whether a car-driver is relaxed or stressed when the driver has to drive in a predefined route from one starting point to a specific destination and return to the starting point within predefined time duration. Besides, drivers are warned about the remaining time to reach the destination. Five sensor signals - Heart Rate (HR), Finger Temperature (FT), Respiration Rate (RR), Carbon-di-oxide (CO2) and Oxygen Saturation (SpO2) have been recorded. This case study has been adopted from [4].

In this case study, all five sensor signals are of stream data. Heart Rate (HR) sensor's primary context is recorded heartbeat. Heartbeats have specific values in a specific time. Besides, Heart Rate is dependent on particular location of the driver. Similarly, other sensors' recorded data have specific values in specific time. Further, all of them have auxiliary contexts. Such as Heart Rate has auxiliary contexts location, age, weight etc. According to this case study, the driver's recorded sensor data will be a *Collection*. Driver will be a *Family*. Further, driver has five *Primary Contexts* - *Heartbeat*, *Finger Temperature*, *Respiration Rate*, *Carbon di-oxide* and *Oxygen Saturation*. Each *Primary*
Context has values and related time stamps. Besides, all are related to Auxiliary Context such as location, body size. Key elements of this case study have been listed below.

## Drivers' recorded Data (Driver)

Driver (Heart Rate, Finger Temperature, Respiration Rate, Carbon di Oxide, Oxygen Saturation);

Heart Rate ({heartbeat, time stamp}, {BODY_WEIGHT, AGE, BODY_POSITION, GENDER, MEDICAL_HISTORY, DRIVER'S LOCATION});

Finger Temperature ({temperature, time stamp}, {AGE, GENDER, MEDICAL_HISTORY, DRIVER'S LOCATION});

Respiration Rate ({respiration_rate, time stamp}, {GENDER, MUSCLE TYPE, DRIVER'S LOCATION});

CO2 ({amount of CO2, time stamp}, {DRIVER'S LOCATION});

SpO2 ({amount of SpO2, time stamp}, {DRIVER'S LOCATION})

Nomenclatures of key elements in the case study are represented as, (i) Collections are in “bold” letters; (ii) Families are in “italics” letters; (iii) Primary Stream Contexts are in “small” letter cases; and (iv) Auxiliary Stream Contexts are in “CAPITAL” letter. In this section, the case study has been implemented using the ontology editorial tool Protégé. Key constructs of the case study have been mapped towards Protégé as specified in section 2. Fig 3 is displaying the partial ontology graph of this case study showing only heart rate stream along with its auxiliary contexts. The graph is obtained through OntoGraf plug-in of Protégé.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** The partial ontological graph displaying Primary Context of Heart Rate using Auxiliary Context and obtained through OntoGraf plug-in in Protégé</figcaption></figure>
# 5 Features of Proposed Conceptualization

Proposed conceptualization possess several crucial features. Those features are *Abstraction* and *Reusability*, *Adaptability*, *Flexibility*, *Interoperability*, *Productivity* and *Context Sensitivity*.

(i) *Abstraction* and *Reusability*: Proposed conceptualization is in high-level abstraction due to representation of data streams independent of any domain. Hence, it is reused in large numbers of domain.

(ii) *Adaptability*: Proposed conceptualization is able to recognize evolving contextual information using *Reverse_has_auxiliary_context*. Thus, it is adaptable towards changing surrounding environment.

(iii) *Flexibility*: Using this proposed conceptualization bounded, unbounded, fixed and flexible partition of bounded sequence of data streams are represented through Frame, Segment and Window. In this way, the proposed conceptualization is flexible.

(iv) *Interoperability*: With the aid of generic formal semantics, proposed conceptualization provides interoperable uniform representation towards heterogeneous data streams and streaming databases.

(v) *Productivity*: The proposed conceptualization is productive as through this specification compatibility among different heterogeneous data streams, streaming databases and applications can be maximized.

(vi) *Context Sensitivity*: The proposed conceptualization is able to recognize related contextual information of both data streams and resources. Thus, the proposed model is context sensitive. This further facilitates validation and analysis of data streams.

# 6 Conclusion and Future Work

The paper has proposed an ontology driven common semantics towards context-dependent data streams and heterogeneous streaming databases. The objective of the proposed work is to model data streams and related contexts in a uniform way so that strong interoperability can be sustained among heterogeneous applications utilizing data streams. The novelty of the proposed ontology driven conceptualization is to support in realization of continuous temporal nature, static and evolving contexts related to data streams, homogeneity in heterogeneity formats, and rapid availability of data streams. The proposed conceptualization is capable to provide generic semantics towards contents of data streams and resources producing those data streams. Further, the proposed conceptualization is flexible enough to represent discreteness within infinite data streams and provide choices of fixed or variable partitions of data streams for storing and retrieval purpose. In this way, the proposed conceptualization may facilitate in future in deriving knowledge and decisions from data streams.

Future work will include semantical validation of the proposed ontology driven conceptualization of stream data. Further, ontology driven formal specification of a query language for retrieval of data streams is another important future work.
References

1. Abadi, D.J., Carney, D., Çetintemel, U., Cherniack, M., Convey, C., Lee, S., Stonebraker, M., Tatbul, N., Zdonik, S.: Aurora: a new model and architecture for data stream management. The VLDB Journal—The Int. J. on Very Large Data Bases. 12(2), 120-139 (2003).

2. Appelrath, H., Geesen, D., Grawunder, M., Michelsen, T., Nicklas D.: Odysseus: a highly customizable framework for creating efficient event stream management systems. In: 6th ACM Int. Conf. on Distributed Event-Based Systems, pp. 367-368. ACM, New York (2012).

3. Arasu, A., Babcock, B., Babu, S., Cieslewicz, J., Datar, M., Ito, K., Motwani, R., Srivastava, U., and Widom, J.: Stream: The stanford data stream management system. Technical Report 641, Stanford InfoLab (2004).

4. Begum, S., Barua, S., Filla, R., Ahmed, MU.: Physiological sensor signals classification for healthcare using sensor data fusion and case-based reasoning. Expert systems with applications. 41(2), 295-305 (2014).

5. Compton, M., Barnaghi, P., Bermudez, L., Castro, R.G., Corcho, O., Cox, S., Graybeal, J., Hauswirth, M., Henson, C., Herzog, A., Huang, V., Janowicz, K., Kelsey, W. D., Phuoc, D. L., Lefort, L., Leggieri, M., Neuhaus, H., Nikilov, A., Page, K., Passant, A., Sheth, A., Taylor, K.: The SSN ontology of the W3C semantic sensor network incubator group. Web Semantics: Science, Services and Agents on the World Wide Web. 17, 25-32 (2012).

6. Ediger, D., Jiang, K., Riedy, J., Bader, D. A.: Massive Streaming Data Analytics: A Case Study with Clustering Coefficients. In: 2010 IEEE Int. Sympo. on Parallel & Distributed Processing, Workshops and Phd Forum (IPDPSW, 2010), pp. 1-8 (2010).

7. Forrest, J.: stream: A Framework for Data Stream Modeling in R. B.S. Thesis, Southern Methodist University, Dallas, TX, United States, (2011).

8. Guarino, N., Oberle, D., Staab, S.: What is an Ontology?. Handbook on Ontologies, second edition, ed: Springer-Verlag, pp. 1-17 (2009).

9. Henson, C. A., Neuhaus, H., Sheth, A. P., Thirunarayan, K., Buyya, R.: An Ontological Representation of Time Series Observations on the Semantic Sensor Web. In: 1st Int. Workshop on the Semantic Sensor Web (SemSensWeb 2009), pp. 79-94 (2009).

10. Horridge, M.: "A Practical Guide to Building OWL Ontologies Using Protégé 4 and COODETools", Edition 1.3, The university of Manchester (2011). https://mariaiulianadascalu.files.wordpress.com/2014/02/owl-cs-manchester-ac-uk-eowltutorialp4_v1_3.pdf.

11. Kramer, J., Seeger, B.: Semantics and implementation of continuous sliding window queries over data streams. ACM Trans. on Database Systems (TODS). 34(1), 4:1-4:9 (2009).

12. Wang, W., De, S., Toenjes, R., Reetz, E., Moessner, K.: A Comprehensive Ontology for Knowledge Representation in the Internet of Things. In: 11th Int. Conf. on Trust, Security and Privacy in Computing and Communications (IEEE TRUSTCOM), pp. 1793-1798. IEEE Computer Society (2012).

13. Wang, X., Zhang, X., Li, M.: A Survey on Semantic Sensor Web: Sensor Ontology, Mapping and Query. Int. J. of u- and e- Service, Science and Technology, 8(10), 325-342 (2015).

14. Banerjee, S. Sarkar, A.: Ontology Driven Meta-Modeling for NoSQL Databases: A Conceptual Perspective. Int. J. of Software Engg. and Its Applications, Science & Engineering Research Support Society (SERSC). 10(12), 41-64 (2016).

15. Zaniolo, C.: Logical foundations of continuous query languages for data streams. In: Second Int. Workshop, Datalog 2.0, pp. 177-189. Springer-Verlag Berlin Heidelberg (2012).