## 3 Context Modeling  
### Adjustment of Categorization Schemata  
Reviewing the existing categorization schemata (see Section 2.1), and based on the premise that the ideal context model should be based on a combination of schemata in order to capture context from two perspectives, the following three categorization schemata were selected: 5 Ws [30], operational schema of [33] and categories of event and time-driven contexts [12]. Each of them captures different aspects of context, while their synthesis can be exploited to develop a better context model, which not only represents the conceptual correlation of the data to a situation, but also the circumstances of data generation and their variability. Such a model will be able to capture the context of an area (conceptual aspect) but also describe which data need to be updated on what condition (implementation aspect). Next, an extension and adaptation of each one of the original schemata included in the proposed context model are presented. On the first schema [30], the who corresponds to the user but in the proposed model, it is extended to any smart device of an IoT ecosystem as an autonomous entity that exploits context awareness. The what is closely related to activity, but may also include a service (as a potential activity). The when encompasses two types of temporal contexts: the timestamp, which is related to an observation, and the period during which an observation is captured (e.g., during bedtime). The former is not considered an autonomous contextual entity but a parameter of a sensed observation or derived information. The where is conceptually related to locations of varying size, but traditional localization cannot represent a translocation activity, which should be addressed by complex location entities, such as \"along a bus ride\". Lastly, context data corresponding to the why question are either derived information, meaning that the reasoning process assumes why a certain activity is executed, or explicit user input. \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Name** & **Modeling** & **Reasoning** & **Heterogeneity** & **Scalability** \\ \hline SmartTweet [73] & Key-value & Rules & No & No \\ Location [25] & Key-value & Binary Tree & No & No \\ IRME [74] & Graphical & Rules & Yes & Limited \\ SCRABS [22] & Ontology/key-value & Rules & Yes & Yes \\ MUST [75] & Key-value & Rules/ML & Yes & Yes \\ Paths [76] & Graphical & Rules & Yes & No \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Overview of middleware for CH environments. On the second schema [33], a merging of static and profiled data is proposed since from an implementation point of view, an IoT platform does not distinguish between them. The necessity lies in the knowledge of whether the required contextual data are sensed (thus a series of actions, such as collection, fusion and processing, are performed) or not (thus only data retrieval is performed). On the other hand, sensed data are split between sensory data and user input, a distinction that interests a CA system during a context retrieval procedure and affects its reliability and responsiveness. In conclusion, the adapted schema includes the following types of data: user input, sensed, profiled, and derived. The third schema [12] represents context that is created based on an event or on specific timeframes. A third type of context is added in the proposed model, context that is created on demand. Let us illustrate the differences between those three types with a temperature sensor as an example. The sensor may send its observation every five minutes (time-driven), every time it falls under a certain value (event-driven), or every time it is asked to do so. Some sensors may be able to function under all three conditions, but most will only be programmed to function under one of them. A fourth type of context is proposed that is archived and is related to past observations.