Keywords

1 Introduction

Context-awareness [1] is receiving much attention in numerous application domains - from mobile health monitoring [2] to drone-driven monitoring in areas affected by disruptive events [3]. Information Systems (IS) incorporate context-awareness in order to automatically adapt to changes in their system and social environment. The increasing IS complexity demands such capabilities but at the same time careless design of context-awareness can introduce new risks because the services delivered by IS concern the context - it is possible that an IS derives a wrong conclusion regarding its context, e.g., due to faulty measurements, misinterpretation of the data, or incorrect reasoning based on the data; then those services would affect the context with possibly serious consequences (here the impact is not limited to users, but may extend to other elements of the context, such as machines, processes, and so on). Hence, we argue that it is important to have correctly functioning IS that are capable of properly and continuously establishing the context and adapting to it accordingly – this is adaptive service delivery and context-awareness is essentially related to it.

Extending previous work on a conceptual framework [4], this paper presents work-in-progress on improving context-aware servicing of user needs. What is left beyond our scope are adaptations that may concern system internal processes and public values [5]. Hence, we face the essential challenge of adequately capturing the user situation, such that situation-specific services can be provided accordingly. Sensor technology is of key importance in this regard [6]: in many cases sensors are capable of providing useful low-level data that in turn can go (in some cases) through fusion algorithms (because sometimes many sensors have to be used in combination and their output needs to be converged), interpretations, and so on, for the sake of extracting higher-level information that is useful for the system in adapting its behavior. We argue that what is to be taken into account with respect to the extraction of context information is as follows: (i) Data can be represented and communicated in different ways; (ii) The quality of data can be such that it does not allow reliable inference; (iii) Data can be about different domains which have to be semantically integrated.

We have identified two challenges in this regard:

  • Challenge 1: The extraction of context information is not always possible with pre-defined rules (this is what is done in many cases) that use Boolean expressions; they directly refer to data values to evaluate user situations. Sometimes such rules would become too complex, would not be effective, or cannot be anticipated at design time.

  • Challenge 2: We are to count on context indicators in establishing the user situation but this is not always a matter of “physical” things (that can be “easily” captured), such as vital signs, location, and so on; it is sometimes a matter of “mental” things, such as intentions and capturing such indicators is considered difficult.

In our view, data analytics [7] can be applied to develop algorithms for performing the extraction task based on training data. In some cases, this would not only replace or complement rules (referring to Challenge 1) but would also allow for capturing “non-physical” context indicators (referring to Challenge 2). Observing the current scientific literature, we would lean towards probabilistic approaches (in general), opting for considering Bayesian Modeling and particularly the Naïve Bayesian Classification Approach [8] because it is: (i) effective as it concerns predictions that are based on training data; (ii) rarely misleading in comparatively “simple” cases, which holds for most real-life cases, as opposed to natural-science-related cases where numerous possible outcomes may apply to any situation; (iii) easily applicable in terms of hardware and software capabilities. Hence, we study the adequacy and usefulness of applying probabilistic approaches together with rules, in establishing and managing the extraction of context information that in turn is needed for the appropriate context-aware servicing of user needs.

After providing relevant background information in Sect. 2, we will present in Sect. 3 an analysis that considers context indicators and corresponding capturing mechanisms. Our proposed solution directions will be outlined in Sect. 4 and we will conclude the paper in Sect. 5.

2 Background

As for the notion of “system”, we refer to the SYSTEMICS conceptualization of Mario Bunge [9,10,11]:

$$ \begin{array}{*{20}l} {C(\sigma ) = \{ x \in \Gamma |x \prec \partial \} } \hfill \\ {E(\sigma ) = \{ x \in \Gamma |x \notin C(\sigma ) \wedge \exists y;y \in C(\sigma ) \wedge (x \triangleright y \vee y \triangleright x)\} } \hfill \\ {S(\sigma ) = \{ \langle x,y\rangle |(x \triangleright y \vee y \triangleright x) \wedge (x,y \in C(\sigma ) \vee (x \in C(\sigma ) \wedge y \in E(\sigma )))\} ,} \hfill \\ \end{array} $$

envisioning composition (C), environment (E), and structure (S) – see above. A system comprises entities and those entities are featuring the SYSTEM COMPOSITION. The way they are related among each other defines the SYSTEM STRUCTURE. Finally, the entities that are outside the system but interact with entities that are inside the system (driven by the system goal) represent the SYSTEM ENVIRONMENT. For the sake of brevity, we are not going to discuss those notions in more detail. What needs to be noted with regard to the current paper is that we use the term “context-aware system”, envisioning either purely software systems (composed of software components), or IS (“information system” is a broader notion compared to “software system” because it reflects not only software entities but also hardware entities, human agents, and so on), or just organizational (human-centric) systems.

Fig. 1.
figure 1

A vision of context-aware servicing

Full size image

In a’19 paper, we have carried out a literature review [12] that was taken into account in our constructing a context-awareness conceptual framework [4]. Referring to it, we view a context-aware system as delivering services to users in support of corresponding user needs (see Fig. 1), adapting this to the user situation. In establishing it, it is essential to adequately extract and manage information that concerns the user. Hence, as the figure suggests, the context-aware service delivery counts on context information (see the dashed line at the central part of the figure). As mentioned above, this information concerns the user (see the dashed line at the right side of the figure) in the sense that user-related contextual details are used to establish the situation of the user.

As stated already, in the current paper we only consider the perspective of maximizing the user-perceived effectiveness (hence, adapting the delivered services to the situation of the user), and we are not focusing on service adaptations driven by desires to optimize system-internal processes and/or to conform to relevant public values.

Because of the limited scope of this paper, we are not providing further elaboration in the current section and we “step” on what was done in two previous papers [4, 12].

3 Context Indicators

According to Hincks: “Contextual indicators often (although not always) take the form of quantifiable variables which are used to help describe and measure wider social, environmental, economic, physical, and demographic contexts in which a particular phenomenon is operating” [13]. By “context indicators” we mean types of details that are relevant to possible situation types we are interested in. Take as an example the tele-health-monitoring of persons where two situation types are considered, namely: “Normal situation” and “Emergency situation”. Then we could consider vital signs (such as blood pressure, pulse, and so on) reflected in corresponding values (captured at a point in time) as indicator for “what is going on” – in this case: whether the situation is normal or urgent.

Fig. 2.
figure 2

Clustering context indicators

Full size image

Inspired by our experience and not claiming exhaustiveness we have identified several key indicator types, namely: identity, vital signs, location, timing, behavior, and intention, visualizing this (using OWL notations [14]) – see Fig. 2.

Further, we have provided a clustering accordingly – see the three colored areas on the figure. The first cluster (from left to right) concerns things that characterize the user himself/herself, such as identity and vital signs. The second cluster concerns “environmental” (with regard to the user) features, such as location and timing. The third cluster concerns the physical/mental “activity” of the user, such as behavior and intention. Finally, these all are to be measurable things, such that we are able to “extract” values that would indicate for corresponding situations.

Hence, an important question is how to deal with those measurements. Our observation is that:

  • There are many sensor-driven ways of establishing the identity of a person, for example: fingerprint/iris scanners, ID card readers, and so on. Then depending on who the user is, the context-aware system could adapt its behavior accordingly.

  • There are blood pressure sensors, pulse sensors and other sensors that are helpful in vital-signs-related measurements, done for establishing the situation of the user.

  • It is easy establishing the location of a person and/or time-stamping his/her activity, just counting on the location/timing services of the person’s smartphone. Then the context-aware system could adapt its behavior based on the location of the user and/or taking into account the timing.

  • Often it is possible capturing the behavior of a person by means of sensors – sensing that a person enters a gym, sensing that the person is sleeping, sensing that the person is using his/her smartphone, sensing that the person is typing, and so on. Sometimes it is even possible “measuring” the behavior of a person – for example, measuring the accuracy or stress in typing, by analyzing the keyboard/mouse pressings/movements. Then depending on the behavior type (and possibly also on the corresponding condition of the user) the context-aware system could adapt its behavior accordingly.

  • Nevertheless, it would be much more difficult “measuring” intentions because sensors are mostly powerful in capturing “physical” things, such as the ones considered above.

Still, intentions are important in this regard because often the user situation is much related to what the user intends to do. Depending on this, we would have particular user needs that in turn would need to be addressed in a corresponding way by the context-aware system.

Hence, we reinforce our claim that capturing (and measuring) “mental” things, such as intentions, is an important challenge relevant to context-aware systems.

4 Solution Directions

Addressing the challenges that were stated in the Introduction and elaborated in the previous section, we assume that “mental” things, such as intentions, are hard to capture (and measure) by means of sensors and supported by rules that use Boolean expressions. Just to give an example: the blood pressure of a person is measured by means of sensors, and there is a simple rule that directs us – if the value is above a threshold, then the situation is considered “urgent”; otherwise, the situation is considered “normal”. This would not work for “mental” things firstly because we have no sensors to capture/measure them (How to capture intentions?) and secondly, because “mental” things are not always straightforwardly relatable to user situations, which in turn means that rules using Boolean expressions cannot help (How could a laptop replacement intention work out if the person is running low on finances, for example?).

This draws our attention to statistics, taking into account that anything dealing with the collection, processing, analysis, or interpretation of numerical data belongs to the domain of statistics [15]. On top of that, we are interested in considering: (i) probabilities, acknowledging that very many current real-life processes are probabilistic (as opposed to deterministic) [16]; (ii) current data analytics, acknowledging the possibilities of today to acquire huge volumes of (sensor) data and derive classifications, clusterings, associations, and so on [7]. Finally, we consider Bayesian Data Analysis as an intersection of those influences, where statistics, probabilities, and data analytics are brought together for the sake of predicting a situation [17].

As mentioned and motivated in the Introduction, we opt for considering the Naïve Bayesian Classification Approach in this regard – this approach takes as a basis a number of attribute vectors Xi = (xi1, xi2,.. xin); each vector depicts n measurements concerning n corresponding attributes (applied for each of the vectors Xi); there are m hypotheses considered with regard to this vector space, namely: Hypothesis 1 (C1), Hypothesis 2 (C2). Hypothesis m (Cm), called “classes”; finally, we know the class for each vector Xi; then the approach allows us to predict the class for each new vector V = (v1, v2,.. vn) for which vi reflects attribute values concerning the same n attributes mentioned above [7, 8]. For the sake of brevity, we will not go in more detail concerning the approach. Moreover, we have discussed it as well as the corresponding Bayes’ theorem in one of our previous papers [12].

Taking a CONCEPTUAL PERSPECTIVE, we justify the relevance of the approach as follows:

  • We may consider the classes (see above) as reflections of corresponding user needs;

  • We may assume that acquiring attribute values (that concern “other users”) is realistic because in many cases we currently have technical/technological means of achieving this;

  • We could therefore predict user needs based on such values, trusting the approach that in turn is based on the abovementioned theorem.

For the sake of ILLUSTRATION, we provide partial exemplification, considering a simple and popular example, namely the AllElectronics example, presented and discussed in [7] – see Fig. 3.

Fig. 3.
figure 3

Class-labelled training tuples from the AllElectronics customer database [7]

Full size image

The figure depicts, with regard to 14 customers, 14 corresponding attribute-value vectors featuring values for the following four attributes: “age”, “income”, “student”, and “credit_rating”. It is depicted as well whether or not each of the 14 customers has purchased a computer – this points to two corresponding hypotheses - effectively H0 and “not H0”, labelled as C1 and C2, respectively (so, we can see that the first customer has not purchased a computer, the second customer has not purchased a computer either, the third customer has purchased a computer, and so on).

The goal in our example is to classify the data tuple X: {senior,high, no, fair}. This is what we do (see below), applying the Naïve Bayesian Classification Approach.

According to the approach, we need to maximize P(X|Ci) x P(Ci), i = 1,2 where P(C1) = P (buys_computer = yes); P(C2) = P (buys_computer = no); “P” stands for “probability”.

figure a

Imagine that the sales managers at the AllElectronics store anticipate particular user needs concerning those customers who would most probably purchase a computer and different user needs concerning those customers who most probably would not purchase a computer – the former would be treated with special attention and offered detailed information featuring the best computer offers while the latter would be “left” with the broad variety of items offered at the store. This actually means adapting the AllElectronics’ “behavior” based on the user needs that are predicted using training data.

Thus, servicing user needs in a context-aware way is not only possible when establishing the user situation by means of sensors and applying rules accordingly but is also possible by means of data analytics and probabilistic modeling, when the user situation is predicted using training data.

5 Conclusions

Context-awareness essentially concerns adaptive service delivery, for which three adaptation perspectives are possible, viz. serving (i) user needs; (ii) system needs; and (iii) public values. Addressing (i) in the current paper, we have essentially focused on the goal of adequately capturing the user situation, such that situation-specific services can be provided accordingly, acknowledging the key importance of sensor technology + rules in this regard and identifying two challenges: (a) The extraction of context information is not always possible with pre-defined rules that use Boolean expressions; (b) Often capturing of such “mental” context indicators, such as intentions, is considered difficult.

We have put those challenges “against” our conceptual model featuring the context-aware servicing of user needs (which model is rooted in previous studies), considering on top of that context indicators, offering a relevant analysis and clustering.

On that basis, we have stated and justified a claim that the Bayesian Data Analysis (BDA) could be useful in some cases when it is possible to predict (using training data) the user needs. This is considered a helpful alternative in situations when using sensors poses limitations and/or when the extraction of (sensor-based) context information is not so easy supported by pre-defined rules.

BDA (and particularly the Naïve Bayesian Classification Approach) is capable of classifying a data tuple (featuring attribute values) with regard to pre-defined hypotheses (classes), by using the attribute values (and corresponding class “values”) of other data tuples as training data and we see different classes as pointing to corresponding user needs. Hence, we are capable of PREDICTING user needs using as training data the “historic” data featuring previous users. We have partially illustrated this by means of a small example – we have considered the famous AllElectronics example.

The limitations of our work are three-fold:

  • We have not conceptualized sufficiently our views to establish/elaborate in what situations sensors would be the best solution and in what situation predictions would be the best solutions.

  • We have only considered a simple example where just two classes are considered (H0 and "not H0"), not addressing cases where the consideration of many hypotheses would be needed.

  • We have not discussed the “probabilistic risk” behind the classifier’s prediction – obviously “52% vs 48%” is different compared to “82% vs 18%” but the classifier does not offer such “sensitivity”.

Hence, we plan as future work to: (1) study in depth in what situations it would be more appropriate to count on sensors and in what situations it would be more appropriate counting on predictions; (2) address situations featuring more hypotheses (classes); (3) carry out a case study for the sake of acquiring more empirical insight, related to our research.