=Paper=
{{Paper
|id=Vol-1220/paper3
|storemode=property
|title=Configuring Decision Tasks
|pdfUrl=https://ceur-ws.org/Vol-1220/03_confws2014_submission_7.pdf
|volume=Vol-1220
|dblpUrl=https://dblp.org/rec/conf/confws/StettingerFJNLR14
}}
==Configuring Decision Tasks==
https://ceur-ws.org/Vol-1220/03_confws2014_submission_7.pdf
Configuring Decision Tasks
Martin Stettinger1 and Alexander Felfernig1 and Michael Jeran1 and Gerald Ninaus 1
and Gerhard Leitner 2 and Stefan Reiterer 3
Abstract. In most cases, decision tasks are individual and different we represent a decision task configuration problem as a constraint
decision tasks require different combinations of features. Features satisfaction problem [12] and [5] (CSP – see Definition 1).
can be, for instance, special preference visibilities during the deci-
sion process or specific heuristics that support the recommendation Definition 1 (Constraint Satisfaction Problem). A CSP con-
of decisions. To find the right features for a decision task it is essen- sists of (1) a set of finite-domain variables X = {x1 , x2 , ..., xn }
tial to offer a corresponding configuration functionality. In this paper and (2) a set of constraints C = {c1 , c2 , ..., cm }. For each variable
we illustrate how the design of a decision task can be represented as xi out of X there exists a finite set Di (domain of the variable)
a configuration problem. The underlying configuration knowledge is of possible assignments. Possible variable assignments can be
already integrated in a tool called C HOICLA. limited via constraints. A complete assignment (every variable has a
corresponding value) which is consistent with the constraints in C is
1 Introduction denoted as a solution for a CSP.
Decisions have to be taken in different situations - for example a
decision about the destination for the next holidays or a decision For the purpose of better understandability we use a feature
about which restaurant to choose for a dinner with friends. Decision model notation to express variability properties of decision tasks.
scenarios can differ from each other in terms of their process design. A feature model (FM) represents a set of possible features and
Some decision scenarios rely on a preselected decision heuristic relationships between them. Features are arranged hierarchically
that defines the criteria for taking the decision, for example, a group which is basically a tree structure with one root feature [2]. Within
decides to use majority voting for deciding about the next restaurant this tree structure the nodes are the features and the edges are the
visit. Furthermore, the visibility of the preferences of other users relationships (constraints). A more detailed discussion of different
is an important feature that can be configured by the creator of a feature model representations can be found in [1], [2] and [3].
decision task.
Six different types of constraints (relationships) are typically
In this paper we show how the design of decision tasks (the used for the construction of feature models ([1], [2]): mandatory,
underlying process) can be defined as a configuration problem. The optional, alternative, or, requires and excludes. Feature models
major advantage of this approach is that making the process design are representing configurable products which can be formalized
of decision tasks configurable introduces the flexibility that is needed in the form of a CSP. A feature f is included if the value is set
due to the heterogenity of decision problems. This way we are able to 1 - otherwise it is said to be excluded. We will exemplify this
to build a model that is flexible with regard to the implementation formalization on the basis of feature model depicted in Figure 1.
(generation) of problem-specific decision applications. The knowl- Figure 1 shows a fragment of the C HOICLA feature model 4 .
edge representations introduced in the following are included in the The CSP representation of the feature model depicted in Figure 1 is
C HOICLA decision support environment (see www.choicla.com). the following:
V = {f1 , f2 , ..., f21 }
The remainder of this paper is organized as follows. In the
next section (Section 2) we discuss features that are essential to the
dom(f1 ) = dom(f2 ) = ... = dom(f21 ) = {0, 1}
design of a decision task. In Section 3 we introduce dependencies
that exist between features. In Section 4 we provide insights into
group recommendation approaches integrated in the C HOICLA c1 :f1 ↔ f2
environment. We then discuss related and future work and thereafter c2 :f1 ↔ f3
conclude the paper. c3 :f1 ↔ f4
2 Configuring a decision task c4 :f1 ↔ f5
c5 :f6 → f1
In the following we discuss different features that are relevant
when designing (configuring) a decision task. On a formal level, c6 :(f7 ↔ (¬f8 ∧ f3 )) ∧ (f8 ↔ (¬f7 ∧ f3 ))
1 c7 :(f9 ↔ (¬f10 ∧ ¬f11 ∧ f4 )) ∧ (f10 ↔ (¬f9 ∧ ¬f11 ∧ f4 ))
Graz, University of Technology, Austria, email:
firstname.lastname@ist.tugraz.at ∧ (f11 ↔ (¬f9 ∧ ¬f10 ∧ f4 ))
2 Alpen Adria University, Austria, email: gerhard.leitner@aau.at
3 SelectionArts Intelligent Decision Technologies GmbH, Austria, email: 4 A more in-depth discussion of the C HOICLA decision support environment
s.reiterer@selectionarts.com can be found in [18].
Figure 1. Fragment of the C HOICLA feature model. In this model, fi are used as abbreviation for the individual features, for example, f1 is the short notation
for feature Decision Task (Application).
c8 :(f12 ↔ (¬f13 ∧ f5 )) ∧ (f13 ↔ (¬f12 ∧ f5 )) of such a scenario is the group-based decision regarding a holiday
destination or a hotel [10]. In this context, each user should be
c9 :f14 ↔ f10
allowed to add relevant alternatives. An example scenario of the
c10 :f15 → f10 third case (only external users can add alternatives) is the support of
c11 :f16 ↔ f10 group-based personnel decisions – in this context it should be pos-
c12 :f17 → f10 sible that persons apply for a certain position (the application itself
is interpreted as the addition of a new alternative to the decision task).
c13 :f18 → f10
c14 :f14 → f15 Scope. The scope of a decision task denotes the external visi-
c15 :f16 → f17 bility. The scope ”private” allows only invited users to participate,
c16 :f16 → f18 i.e., the task is not visible for other users except those who have
been invited. If the scope is ”public”, the decision task is visible
c17 :¬(f16 ∧ f12 ) to all users – this is typically the case in the context of so-called
c18 :(f19 ↔ (¬f20 ∧ ¬f21 ∧ f15 )) ∧ (f20 ↔ (¬f19 ∧ ¬f21 ∧ f15 )) Micro-Polls. The selection of the scope has an impact on other
∧ (f21 ↔ (¬f19 ∧ ¬f20 ∧ f15 )) features – related aspects will be discussed in Section 3.
We will now discuss different basic properties of decision task Preference visibility. The visibility of individual preferences
configuration problems. In this context we explain the individual of the other participants involved in a decision process can have an
features and constraints depicted in Figure 1. impact on decision quality (see [6], [10], and [11]). There occur
some decision scenarios where all participants should exactly know
Basic properties. Each decision task is characterized by a which person articulated a rating of an alternative. If, for example,
name, a corresponding description, and a picture that represents a date for a business meeting is the topic of the decision task it is
the decision task (summarized in the feature Basic Properties for very essential to find a date where all division managers can attend
simplification purposes). the meeting and therefore it is important to know the individual
preferences of the participants in that case. But there are of course
Management of alternatives. There are different possibilities decision scenarios where preference visibility can lead to disad-
to support alternative management within the scope of a decision vantages for some participants but still some kind of transparency
task. First, only the creator of a decision task is allowed to add of the preferences is helpful to come to the best decision. In such
alternatives – this could be the case if a person is interested to know cases a summary of all given preferences of an alternative is a good
the opinions of his/her friends about a certain set of alternatives way to support the participants best during the decision process. A
(e.g., alternative candidates for the next family car). Another summary prevents all participants from statistical inferences but still
related scenario are so-called ”Micro-Polls” where the creator is can help participants who are not sure about which rating to select.
only interested in knowing the preference distribution of a larger
group of users. Second, in some scenarios it should be possible Email notification. If this feature is set, emails can be used to
that all decision makers can add alternatives – a typical example exchange information about the current state of the decision process.
For example, the status update interval specifies in which intervals
participants of a decision process receive a summary of the current
X
GDIS(s) = minarg(d∈{1..5}) ( |eval(u, s) − d|) (4)
status of the decision process. The active participation reminder is u∈U sers
a feature which helps to trigger need for closure. If this feature is
set, a maximum inactive time (without looking at the current status Finally, Ensemble Voting (see Formula 5) determines the majority
of the decision task) for the participants can be set. After this time of the results of the individual voting strategies H = {MAJ, LMIS,
is elapsed an email will be sent to the corresponding participants to MPLS, GDIS}. For example, the ensemble-based majority voting for
encourage an active participation at the decision task. Clocktower is 5.
Recommendation support. In context of group decision tasks [
another very essential aspect is the aggregation function (recom- EN S(s) = maxarg(d∈{1..5}) (#( eval(h, s) = d)) (5)
mendation heuristic). Aggregation functions can help to foster h∈H
consensus in a group decision process, furthermore, user studies
show that these functions also help to increase the degree of the
perceived decision quality (see, for example [6]). Preferences of solution MAJ LMIS MPLS GDIS ENS
individual users can be aggregated in many different ways and there Clocktower 5 3 5 5 5
exists no standard heuristic which fits for every decision scenario. Häuserl im Wald 3 3 5 3 3
La Botte 3 3 5 3 3
To support groups of users in different scenarios the selection of El Gaucho 4 3 4 4 4
recommendation heuristics is a necessary feature which has to be
configured by the creator of a decision task. Some basic aggregation Table 2. Results of applying the aggregation functions to the user
heuristics which can be used in such cases are described below. For preferences shown in Table 1. MAJ = Majority Voting; LMIS = Least
an in-depth discussion of basic types of aggregation heuristics see, Misery; MPLS = Most Pleasure; GDIS = Lowest Group Distance; ENS =
Ensemble Voting. This example is based on the preference information in
for example, the overview of Masthoff [14]. The example given in
Table 1.
Table 1 represents the individual ratings of the participants for the
defined alternatives. The results of applying the decision heuristics Explanations. Explanations can play an important role in decision
discussed below are depicted in Table 2. tasks since they are able to increase the trust of users in the out-
restaurant Martin Dave George Ben
come of a decision process [4]. When configuring a decision task in
C HOICLA, explanations can be selected as a feature of the decision
Clocktower 5 3 5 4
Häuserl im Wald 3 3 5 3 process. In the current version of C HOICLA, explanations are sup-
La Botte 5 3 3 3 ported by simply allowing the creator of the decision process to in-
El Gaucho 4 3 4 4 clude textual argumentations as to why a certain decision alternative
has been selected as ”the final decision”. If this feature is selected,
Table 1. Examples of user-specific ratings with regard to the available the administrator of a decision task has to enter some explanatory
decision alternatives (restaurants).
text, if not, the entering of such a text remains just an option.
Majority Voting (see Formula 1) determines the value (d) that a
majority of the users selected as voting for a specific solution s 3 Dependencies among features
where eval(u, s) denotes the rating for solution s defined by user u.
For example, the majority of votings for Clocktower is 5 (see Table We now discuss examples of constraints that restrict the combina-
2). tions of features as shown in the feature model of Figure 1. The
constraint-based representation of these constraints is shown in the
[ CSP definition of the feature model given in Section 2.
M AJ(s) = maxarg(d∈{1..5}) (#( eval(u, s) = d)) (1)
u∈U sers Scope of a decision. If a decision task is public, there are re-
strictions regarding the support of message interchange (e.g., via
Least Misery (see Formula 2) returns the lowest voting for solution s email) and the visualization of the preferences of other users. In
as group recommendation. For example, the LMIS value for the s = the case that a decision task is private, it is in both cases possible
Clocktower is 3. to choose. Preferences can (but must not) be made visible to other
[ users and the type of possible message interchange can be specified.
LM IS(s) = min( eval(u, s)) (2) The differentiation between public and private decision tasks also
u∈U sers has an impact on other system properties. For example, if a decision
task is defined as private, the corresponding decision application can
Most Pleasure (see Formula 3) returns the highest voting for solution
not be reused by other users, i.e., found as a result via the C HOICLA
s as group recommendation. For example, the MPLS value for the s
search interface.
= Clocktower is 5.
[ Preference visibility. A dependency of type ’requires’ exists
M P LS(s) = max( eval(u, s)) (3)
u∈U sers
between the feature preference visibility and the corresponding
notation of visibility. Preference visibility denotes a functionality
Group Distance (see Formula 4) returns the value d as group recom- where the individual preferences of other users are made visible for
mendation which causes the lowest overall change of the individual the current user. The type of visualization can only be selected in the
user preferences. For example, the GDIS value for s = Clocktower is case that the preference visibility feature is has been selected by the
5 (or, alternatively 4). designer of a decision task.
Figure 2. C HOICLA: definition of a decision task. Basic settings & further configurable features in case the decision makers are allowed to contribute own
alternatives during the decision process.
Email notification. Similar to the visibility of preferences, the
type of supported message exchange (e.g., via email) can only be
specified in the case that the creator of the decision task decided to
support email notifications. As already mentioned, email communi-
cation is only supported if the scope of the decision task is private.
These simple examples already show the need to manage deci-
sion task related variability in a structured fashion. Our knowledge
representation approach allows for a product line oriented develop-
ment of decision support functionalities and makes systems much
more flexible for future requirements and corresponding extensions.
Figure 3. C HOICLA: user interface for addition of decision alternatives.
The dots in the upper right corner of every symbol indicate whether there is
4 Configuring decision tasks in C HOICLA an information in this category available or not. The meaning of the used
symbols is (from left to right): edit, delete, geographical information, files,
In the following we give an example of how a decision task can links and comments.
be configured in the C HOICLA decision support environment
(www.choicla.com). The application knowledge base of C HOICLA
is currently rule-based. For reasons of easier maintenance and adapt-
ability we apply reasoning and CSP for future versions of C HOICLA.
Parts of the user interface that supports a creator of a decision
task are depicted in Figure 2. The possible parametrizations corre-
spond to the features in the model of Figure 1. If, for example, a
specific feature A depends on the inclusion of another feature B, this
is taken into account in the user interface, i.e., such a feature (feature
A) can only be selected, if the other feature (feature B) is also
selected. In the example of Figure 2, the scope of the decision task
is private (only invited users can participate), all decision makers are Figure 4. C HOICLA: user interface for individual voting of decision
allowed to add alternatives, and for all participants of the decision alternatives. Each alternative can be voted by a five-star scale. The tab
Places shows the geographical distribution of the decision alternatives (if
process the preferences of other users are visible (names as well
available). In tab Group Preferences the actual group recommendation as
as preferences). Note that in the C HOICLA environment there are well as the individual preferences of the other users (if feature f 14 is set) is
many additional features that can be selected within the scope of a presented to the users. The process where the ”final decision” can be set is
decision task configuration process. triggered by the button Finalize Choicla.
For understandability reasons we kept our working example simple
and focused on aspects that give the reader an impression of the 5 Related and Future Work
basic underlying configuration problem. The user interface for the
There exist a couple of online tools which support different types of
inclusion of alternatives is depicted in Figure 3.
decision scenarios. The Decider5 is a tool that allows the creation of
Figure 4 shows how the decision alternatives can be voted by the
5 labs.riseup.net.
individual users of a decision task.
issues and decision alternatives – the corresponding recommendation Agency (843492).
is provided to users who are articulating their preferences regarding
the given decision alternatives. Rodriguez et al. [17] introduce
Smartocracy which is a decision support tool which supports the
REFERENCES
definition of tasks (issues or questions) and corresponding solutions. [1] Don Batory, ‘Feature models, grammars, and propositional formulas’,
Solution selection (recommendation) is based on exploiting infor- in Proceedings of the 9th International Conference on Software Product
Lines, SPLC’05, pp. 7–20, Berlin, Heidelberg, (2005). Springer-Verlag.
mation from an underlying social network which is used to rank [2] David Benavides, Sergio Segura, and Antonio Ruiz-Corts, ‘Automated
alternative solutions. Dotmocracy6 is a method for collecting and analysis of feature models 20 years later: A literature review’, Informa-
visualizing the preferences of a large group of users. It is related to tion Systems, 35(6), 615 – 636, (2010).
the idea of participatory decision making – it’s major outcome is a [3] A. Felfernig, D. Benavides, J. Galindo, and F. Reinfrank, ‘Towards
Anomaly Explanation in Feature Models’, Workshop on Configuration,
graph type visualization of the group-immanent preferences. Doo-
Vienna, Austria, 117–124, (2013).
dle7 focuses on the aspect of coordinating appointments – similarly, [4] A. Felfernig, B. Gula, and E. Teppan, ‘Knowledge-based Recom-
VERN [19] is a tool that supports the identification of meeting times mender Technologies for Marketing and Sales’, International Journal
based on the idea of unconstrained democracy where individuals are of Pattern Recognition and Artificial Intelligence (IJPRAI), 21(2), 1–
enabled to freely propose alternative dates themselves. Compared 22, (2006).
[5] Alexander Felfernig, Lothar Hotz, Claire Bagley, and Juha Tiihonen,
to C HOICLA these tools are not able to customize their decision Knowledge-based Configuration – From Research to Business Cases,
processes depending on the application domain and are also focused Elsevier, 2014.
on specific tasks. Furthermore, no concepts are provided which help [6] Alexander Felfernig, Christoph Zehentner, Gerald Ninaus, Harald
to improve the overall quality of group decisions, for example, in Grabner, Walid Maalej, Dennis Pagano, Leopold Weninger, and Flo-
rian Reinfrank, ‘Group decision support for requirements negotiation’,
terms of integrating explanations, recommendations for groups, and
in Advances in User Modeling, eds., Liliana Ardissono and Tsvi Kuflik,
consistency management for user preferences. volume 7138 of Lecture Notes in Computer Science, 105–116, Springer
Berlin Heidelberg, (2012).
The support of group decision processes on the basis of rec- [7] J. Huber, J. Payne, and C. Puto, ‘Adding Asymmetrically Dominated
ommendation technologies is a new and upcoming field of research Alternatives: Violations of Regularity and the Similarity Hypothesis’,
The Journal of Consumer Research, 9(1), 90–98, (1982).
(see, e.g., Masthoff et al. [14]). The application of group recom- [8] K. Jacowitz and D. Kahneman, ‘Measures of Anchoring in Estimation
mendation technologies is still restricted to specific domains such as Tasks’, Personality and Social Psychology Bulletin, 21(1), 1161–1166,
interactive television [13], e-tourism [9, 15], software requirements (1995).
engineering [6], and ambient intelligence [16]. [9] A. Jameson, S. Baldes, and T. Kleinbauer, ‘Two methods for enhanc-
ing mutual awareness in a group recommender system’, in ACM Intl.
Working Conference on Advanced Visual Interfaces, pp. 48–54, Gal-
Future Work. Our future work will focus on the analysis of lipoli, Italy, (2004).
further application domains for the C HOICLA technologies. Our [10] Anthony Jameson, ‘More than the sum of its members: challenges for
vision is to make the design (implementation) of group decision group recommender systems’, in Proceedings of the working confer-
tasks as simple as possible. The resulting decision task should be ence on Advanced visual interfaces, AVI ’04, pp. 48–54, New York,
NY, USA, (2004). ACM.
easy to handle for users and make group decisions in general more [11] Anthony Jameson and Barry Smyth, ‘Recommendation to groups’, in
efficient. Within the scope of our work we will also focus on the The Adaptive Web, eds., Peter Brusilovsky, Alfred Kobsa, and Wolfgang
analysis of decision phenomena within the scope of group decision Nejdl, volume 4321 of Lecture Notes in Computer Science, 596–627,
processes. Phenomena such as decoy effects [7] and anchoring Springer Berlin Heidelberg, (2007).
[12] Alan Mackworth, ‘Consistency in networks of relations’, Artificial In-
effects [8] are well known for single-user cases but are not investi-
telligence, 8(1), 99–118, (1977). Reprinted in Readings in Artificial
gated in group-based decision scenarios. Finally, we will also focus Intelligence.
on the development of further group recommendation heuristics. [13] J. Masthoff, ‘Group modeling: Selecting a sequence of television items
In this context, our major goal is to make the C HOICLA datasets to suit a group of viewers’, User Modeling and User-Adapted Interac-
available to the research community in an anonymized fashion for tion (UMUAI), 14(1), 37–85, (2004).
[14] J. Masthoff, ‘Group Recommender Systems: Combining Individual
experimentation purposes. Models’, Recommender Systems Handbook, 677–702, (2011).
[15] K. McCarthy, M. Salamo, L. Coyle, L. McGinty, B. Smyth, and
P. Nixon, ‘Group recommender systems: a critiquing based approach’,
6 Conclusions in 2006 International Conference on Intelligent User Interfaces (IUI
In this paper we have shown how to represent the design of de- 2006), pp. 282–284, Sydney, Australia, (2006). ACM.
[16] I. Perez, F. Cabrerizo, and E. Herrera-Viedma, ‘A Mobile Decision Sup-
cision tasks as a configuration problem. In this context, we gave port System for Dynamic Group Decision-Making Problems’, IEEE
a short introduction to the C HOICLA group decision environment Transactions on Systems, Man, and Cybernetics, 40(6), 1244–1256,
which supports the flexible design and execution of different types (2010).
of group decision tasks. Compared to existing group decision sup- [17] M. Rodriguez, D. Steinbock, J. Watkins, C. Gershenson, J. Bollen,
V. Grey, and B. deGraf, ‘Smartocracy: Social networks for collective
port approaches, C HOICLA provides an end user modelling environ-
decision making’, in HICSS 2007, p. 90, Waikoloa, Big Island, HI,
ment which supports an easy development and execution of group USA, (2007). IEEE.
decision tasks. [18] Martin Stettinger, Gerald Ninaus, Michael Jeran, Florian Reinfrank,
and Stefan Reiterer, ‘We-decide: A decision support environment for
groups of users’, in Recent Trends in Applied Artificial Intelligence,
ACKNOWLEDGEMENTS eds., Moonis Ali, Tibor Bosse, KoenV. Hindriks, Mark Hoogendoorn,
CatholijnM. Jonker, and Jan Treur, volume 7906 of Lecture Notes in
The work presented in this paper has been conducted in the research Computer Science, 382–391, Springer Berlin Heidelberg, (2013).
project P EOPLE V IEWS funded by the Austrian Research Promotion [19] S. Yardi, B. Hill, and S. Chan, ‘VERN: Facilitating Democratic group
Decision Making Online’, in International ACM SIGGROUP Confer-
6 dotmocracy.org.
ence on Supporting Group Work (GROUP 2005), pp. 116–119, Sanibel
7 doodle.com.
Island, Florida, USA, (2005). ACM.