According to [
Context-aware systems are used to support personalization with regard to the current situation of related users. These kinds of systems can be used to provide personalized explanations too. But this is no easy task, because di erent situations require di erent explanations which should be made available to the users in the speci c situation. This makes it comprehensible for the individual user to understand what has happened in the application and why certain actions are not carried out or lead to an unexpected result, e.g., a common workspace is not created if there are aversions between participants, or an agreement to the data processing is missing that declares an explanation with agreement function. Other situations where the individual characteristics and abilities of the users must be taken into account are may be di erences in language style and level of di culty (e.g., simple language). Also the usage of jargon in notes and help texts for the respective target group is important as well as the provision of data usage reports in accordance with § 15 of the General Data Protection Regulation (GDPR). The challenge of context-based systems is to support the many di erent situations with personalized explanations. In this paper, we address this challenge. For that, we explain our context-based adaptive system approach and our work in a nutshell. Based on this, we introduce sample scenarios in section 3 to illustrate our approach on how to handle di erent situations with suitable explanations. In section 4 we describe our explanation building components and process. After the presentation of related work in section 5, we discuss our approach (cf. section 6) and nish with conclusions and future work in section 7. 2
We develop an extendable context-based adaptive system environment (eCBASE) as a basis system for the development and integration of domain-speci c context-based adaptive applications. eCBASE is designed to support users of the platform and domain-speci c applications in a situation-speci c way. In addition to the support for the use of the application or the processing of artifacts, the environment should also highlight the legal regulations that apply when using the application and explain the consequences for its use. 2.1
Context-based Adaptive Approach We de ne a context-based adaptive approach as the provision of an environment that is able to perceive a situation, recognize the need for action and make an adequate adaptation of the system. This should support users in speci c situations. In doing so, we address the individual needs of the users through personalized adaptations. In a group or collaboration situation, the system has to nd a consent that takes into account the situation and circumstances of the individual group members.
Our context-based adaptive system is based on a formal model that we model using an ontology. We developed
a core model with all necessary concepts and relationships which represents objects and functionalities within
every supported application domain. This model will be extended for di erent scenarios and application domains
at so-called extension points. It provides the basis to represent the context at runtime. For context modelling
we use the OWL 2 Web Ontology Language and the generic four-layer framework for modelling context in a
collaboration environment and the related collaboration domain model presented in [
Extendable context-based adaptive system environment
eCBASE is a common platform of functions and technologies for providing context-based adaptive and
personalized software applications that can be made available for di erent domains. In the so-called core system, we
model domain-independent and domain-speci c objects and relationships as well as fundamental legal aspects,
which must be considered in all future domain-speci c applications. The design of the legal requirements is
passed on to the responsible legal professional of the operating organization or the provider of a domain-speci c
application. eCBASE provides the necessary formal concepts and basic functions for this which are represented
in a legal domain model (cf. [
The application domain is the real-world environment and provides the setting in which a software application
is used, e.g., online learning platforms (cf. [
We explain our approach to generating personalized explanations in eCBASE in the following sections. We start
with the introduction of a collaboration situation in which users can be supported by personalized explanations.
A domain-speci c context-based adaptive application senses the current situation and decides on the basis of
the current available and related instances of the context which adaptation rule should be executed. Due to the
adaptations in the applications by the adaptation rules, situations can occur in which the expectations of the
users are not ful lled (e.g., known action-response patterns do not occur, changes cannot be traced or reasons
of the behavior are unknown). Therefore, it is necessary to explain system processes and data usage, to help
users understand the current situation [
Our scenario takes place in an adaptive personalized learning environment (APLE) in which the instructor has speci ed that groups of three students each have to solve certain course tasks. In our scenario, we assume that a groupspace gets created as soon as three students access the same artifact (i.e. Task A). Figure 1 illustrates three situations in which three users each access the same artifact, what could potentially lead to the creation of a groupspace. Each of these users has personal preferences as shown in Figure 2, which can concern, e.g.,, the type of collaboration (i.e. a shared groupspace; cf. Figure 2, dm:ApplicationFunctionality ) and the collaboration partners (cf. Figure 2, dm:GreyList , dm:BlackList ). These preferences should be taken into account for ethical and legal reasons when creating the groupspace. … dm:User = Alice dm:Application = APLE dm:ApplicationFunctionality = SharedGroupspace dm:Approval = permanent Created on: 12.12.2019 18:04 Limitation: none … … dm:User = Bob dm:Application = APLE dm:ApplicationFunctionality = SharedGroupspace dm:Approval = once Created on: 12.02.2020 08:29 Limitation: Task_A dm:GreyList: John, Steve … … dm:User = Fred dm:Application = APLE dm:ApplicationFunctionality = ContentRecommendation dm:Approval = permanent Created on: 08.02.2020 18:19 Limitation: none dm:BlackList: Steve …
Before the groupspace gets created, the sensing engine gathers information about the current collaboration
situation. The adaptation engine uses this information to create the context. It checks whether an adaption
is possible or not. Therefore, it evaluates all realted adaptation policies (cf. Figure 3). An adaptation policy
consists of a condition (WHEN to DO ) and an action block (DO to END ). As soon as the condition block
evaluates to non null results, the action block gets executed. In [
As shown in Figure 3 (1), we retrieve all users within the current collaboration situation, the context. We iterate over all users to apply the rule "Compliance by Design", i.e. we retrieve the application (getApplicationInContext ) and the related requirement from the users context (getRequirementInContext ) and request an approval for this speci c setting (requestApproval ). As soon as the user approves the request, we call createOrUpdateAcceptedApproval to store the decision in the context and notify the user about this operation.
The adaption policy (2) in Figure 3 takes the second scenario (cf. Figure 1 (2)) into account. Therefore we use the context, i.e. the current collaboration situation, to get relevant users (getUsersInContext ), retrieve the related task they are working on (getTaskInContext ) and retrieve the approvals and preferences. The function getPreferences enables us to retrieve speci c context concepts from a users pro le, in our sample dm:GreyList . The function getTeam uses the above context concepts and relations to check whether a team can be build or not. In the second scenario we are able to build a team. This leads to the execution of the action block, where related explanations will be created, before we check whether we need an additional con rmation or not (because of the grey list). When no con rmation is required we can open the shared groupspace for this team.
To support the third scenario (cf. Figure 1 (3)), we use the adaptation policy (3) in Figure 3. The condition block is similar to adaptation policy (2), despite the retrieval of the concepts dm:BlackList from users preferences. Instances of these concepts indicate that users do not want to collaborate with speci c persons. Therefore we have to take care of it. The function getTeam checks whether there are users present in related black lists of other users that should form this team (cf. third scenario). If this is the case, the action block gets triggered. We do not create a team, but we explain the current collaboration situation and create related personalized explanations so that users get aware of it.
Scenario 1: The rst scenario (cf. Figure 1 (1)) illustrates the situation when Alice and Bob already approved
the usage of the SharedGroupspace (an application functionality) for Task A. The third possible group member
Fred has no approval for the usage of a SharedGroupspace, what leads to a situation that the adaptation rule
"Compliance by Design" (cf. [
(2) WHEN users = getUsersInContext("dm:User") task = getTaskInContext(users) apprs = getApprovalsInContext(users,
"dm:Approval") prefs = getPreferences(users, "dm:GreyList") team = getTeam(users, apprs, prefs, task) (3) WHEN users = getUsersInContext("dm:User") task = getTaskInContext(users) apprs = getApprovalsInContext(users,
"dm:Approval") prefs = getPreferences(users, "dm:BlackList") team = getTeam(users, apprs, prefs, task) (1) uFsOeRrEsAC=H guesteUrsIeNrsuIsneCrosntDeOxt("dm:User") # rule "Compliance by Design" WHEN app = getApplicationInContext(user,
"dm:Application") req = getRequirementInContext(app,
"dm:Requirement") appr = requestApproval(user, app, req) DO createOrUpdateAcceptedApproval(appr) notify(user, appr)
END END
DO expls = createExplanations(team) IF requiresConfirmation(team) THEN
requestConfirmation(team, expls) ELSE
openSharedGroupspace(team, expls)
END END
With the generic process presented in [
In Figure 5 we show the required components to generate situation-speci c personalized explanations for the users. The Adaptation Runtime Environment (ARE) contains the sensing and adaptation engine to apply suitable adaptation policies (AP). Based on the domain model (DM), the sensing rules (SR) are used to generate the state. Applying the contextualization strategies (CS) to the state creates the contextualized state, i.e. the context of the current situation. The contextualized state is used to evaluation the condition blocks of adaptation policies. As soon as an action block can be executed, this is done through the Adaptation Component. To generate personalized explanations, the contextualized state and suitable prede ned templates are given to the Explanation Builder. It generates situation-speci c explanations which are transferred to the Adaptation Component to create and display a user interface artifact.
In Figure 6 we present a rough domain model which contains concepts and relationships to create a contextualized state according to the above introduced scenario. The pre x dm is used for common core concepts in eCBASE. For concepts and relationships of the learning management domain, we use the pre x lms. Does the concepts belong to legal regulations domain we use lr .
The important core concepts dm:Requirement , dm:Condition and dm:Declaration and their dependencies are used to support user control and intelligible explanations. Requirements (dm:Requirement ) are conditions for applications and de ne what an application (dm:Application) or application functionality (dm:ApplicationFunctionality ) must check and take into account during processing. The requirements are not stored as a xed set of rules. Requirements can be related to technical conditions (dm:Technical ), content de nition (dm:Content ) and/or legal regulations (dm:Legal ).
Conditions (dm:Condition) determine what an application (dm:Application) or an application functionality
(dm:ApplicationFunctionality ) has to consider at runtime and how it should deal with certain situations. The
set of rules for the conditions is derived from the requirements, who are de ned by the experts. Declarations
(dm:Declaration) are the interfaces to users which can support comprehensibility and user control. In [
The extensions in Figure 6 belongs to our scenarios we described above. The students (instances of dm:User ) are present in an online course (lms:Course) with learning material (lms:LearningMaterial ). They do learning activities (lms:LearningActivity ) and e.g., work on Task A (instance of lms:Taks ), which are artifacts (dm:Artifact ) and belong to the passive resources (dm:PassiveResource subclass of dm:Resource) within the application APLE. For that, they use a shared groupspace (lms:SharedGroupspace) that must be created (lms:CreateSharedGroupspace) through an action (dm:Action). The shared groupspace uses personal data (dm:Sensitive) of the students (instances of dm:User ). Due to that, they have to decide (dm:Decision) and approve (dm:Approval ) the data usage before accessing the collaboration situation. If a situation requires an approval, as illustrated with Fred, the lr:ApproveDataUsage action is triggered and provides an explanation as lr:ApprovalRequest . The preferences (dm:Preferences ) of the students for the assembling of workgroups are represented as black list (dm:BlackList ) and grey list (dm:GreyList ). 5
Supporting intelligibility of complex context-aware systems is the approach of [
1http://contexttoolkit.sourceforge.net
Enhancements to the explanation component in the Context Toolkit are presented in [
[
The provided explanations are tailored to a situation when the adaptation rule gets executed and explain more general aspects of the situation. The explanations are neither personalized to the users circumstances nor support di erent kinds of explanations. Additionally, the platform does neither support legal regulation nor its integration or explanations about legal conditions. So far, there are no known context-based collaborative systems that support intelligibility for users and legal compliance as our presented approach. 6
We presented an approach on how to support users with personalized explanations within a context-based
adaptive system environment. Our sample scenario used a context-based adaptive learning environment APLE
to illustrate how we deal with di erent collaboratin situations. These situations demand adaptation. We showed
related adaptation policies that are capable of recognizing speci c collaboration situations motivated by ethical
or legal aspects. In our sample scenario, we used di erent preferences of the involved users and the legal
requirements to illustrate it. These constraints can delay or prevent collaboration. Depending on the context,
an appropriate strategy for handling the situation through the context-based application must be applied. In
the presented approach, we address this challenge with generic adaptation policies and the Explanation Builder.
Based on CONTact, our starting platform, eCBASE allows us to handle di erent collaboration situations, which
has already been demonstrated by [
In this paper we presented an approach for collaboration support and personalized explanations in context-based
adaptive systems based on the CONTact platform (cf. [
To address the introduced challenge about the support of many di erent situations with personalized explanations, we combine the adaptation runtime environment of CONTact with the Explanation Builder to support personalization with regard to the current situation of related users. We illustrated the usage and creation of personalized explanations in our sample scenarios and the related adaptation rules.
We described how to create personalized explanations, but we also need to provide intelligible explanations what is a challenging task. To address the intelligibility of explanations a series of user studies needs to be done for each application domain which should be supported by eCBASE. Additionally, we have to nd out, when and what is the right situation to provide explanations. Due to that, future work will focus on user interaction design and the way in which texts are formulated. Both must be integrated in eCBASE. This work was supported by the Research Cluster "Digitalization, Diversity and Lifelong Learning. Consequences for Higher Education" (D2L2) of the FernUniversitat in Hagen funded by the Ministry of Culture and Science of the German State of North Rhine-Westphalia.