Nataliya Kos'myna

Franck Tarpin-Bernard

Bertrand Rivet
email: bertrand.rivet@gipsa-lab.grenoble-inp.fr

Nataliya Kosmyna

Towards Brain Computer Interfaces for Recreational Activities: Piloting a Drone

Keywords: Brain Computer Interface, Engagement, Replication, Drone 1

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Active Brain Computer Interfaces (BCIs) allow people to exert direct voluntary control over a computer system: their brain signals are captured and the system recognizes specific imagined actions (movement, images, concepts). Active BCIs and their users must undergo training (between 10 minutes and 2 months). This skill is also known as BCI training. This makes the signals easier to recognize by the system. This acquisition can take from 10 minutes up to 2 months. BCIs can thus be applied to many control and interaction scenarios of our everyday lives, especially in relation to entertainment [START_REF] Wolpaw | Brain-computer interfaces for communication and control[END_REF].

BCIs have mostly been used in laboratories and in medical applications (e.g. spellers for locked-in syndrome patients [START_REF] Wolpaw | Brain-computer interfaces for communication and control[END_REF]). A few dozen people at most use BCIs at home, as exhibited by the BNCI FP7 roadmap report [START_REF]Future BNCI: A Roadmap for Future Directions in Brain/Neuronal Computer Interaction Research[END_REF]. Moreover, as an emerging and new interaction technology, they offer a good prospect of inspiring people's imaginations and of providing a new and enjoyable way of interaction [START_REF] Mancini | Contravision: Exploring Users' Reactions to Futuristic Technology[END_REF]. For example, personal drones are a popular phenomenon that takes an increasing role in our daily lives. There are "selfie drones" 1 that take off from a user's wrist to take a "selfie" photo, such drones can be controlled by BCIs. Recent press coverage of a BCI system that controls a drone quadcopter [START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] has shown a strong interest in the general public of experiencing BCI control.

In this particular drone piloting application, the training protocol for the BCI is called Operant Conditioning (OC), needs to teach users to harness their brain signals and adapt them so that they can be recognized by the computer, which requires one to two months of rigorous training. Alternatives to OC for BCIs are training protocols based on machine learning that record typical brain signals for a set of mental actions or states and build classifiers to recognize those actions or states. Although training is shorter (10-20 minutes sessions [START_REF] Blankertz | The Berlin brain -computer interface: Accurate performance from firstsession in BCI-naïve subjects[END_REF]), the process requires a continuous focus and concentration from users, is more error-prone than OC and involves feedback to users [START_REF] Lotte | Flaws in current human training protocols for spontaneous Brain-Computer Interfaces: lessons learned from instructional design[END_REF] that is not appealing.

None of the two training paradigms are entirely adequate to let people test the technology in a way that would make them want to try again or even adopt it for enjoyment.

In this work we want to gauge the possibility of producing a BCI trained interactively in short sessions and that provides a viable alternative to OC and standard training protocols.

We introduce a "Co-learning BCI" (CLBCI) that reduces the initial amount of training required before the BCI is functional and that allows an incremental and interactive training process. We want to know if it is better to do one long training session with OC before using the BCI altogether or to have a short training session with CLBCI before every use of the BCI (a balance of quality versus time versus degree of control). We are particularly interested in what happens in the long run by evaluating whether OC and CLBCI are compatible with an overly positive user experience. Moreover, we want to know when OC should be favored over CLBCI and vice versa.

To that end, we perform an experiment over three training durations: 1 day, 1 week, 1 month. We train users in two groups, for all training durations: one group with CLBCI and the other using OC training. We want to see whether CLBCI reaches an acceptable performance for shorter training periods while maintaining the effect of signal variability to a minimum. We also asked users to fill informal questionnaires to share their experiences.

With this experiment we want verify the following hypotheses:

• (H.1): For duration of below one month, using CLBCI leads to better task performance compared to OC. • (H.2): Beyond the one month duration, OC leads to better task performance.

• (H.3): Despite the better performance for OC after a month training, users prefer to train for a shorter period whenever they want to use the BCI, rather than spend a full month training once.

For the evaluation, we apply our system to the drone piloting task used in LaFleur et al. [START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] to pilot an AR.Drone (Figure 1) and we evaluate the task performance of CLBCI compared to OC. The task and the OC implementation are a replication of LaFleur et al's experimental protocol. We use the same evaluation measures and training protocols.

We first present background information on BCIs and their application and then some related work pertaining to control applications and co-adaptive BCI learning. Then, we present the CLBCI system and continue with the experimental protocol and the analysis and discussion of the results.

Background Information and Related Work

In this section we will present background information about BCI systems and then go on to study the state of the art and relevant BCI research for human computer interaction and control applications.

Brain Computer Interfaces

A BCI system 𝐵 must assign a brain signal 𝑆 ! of a fixed duration (an epoch; e.g. 1s) at time 𝑡, to a class 𝐶𝑙 ! from a set of 𝑁 classes 𝐶𝑙, that correspond to a set of brain activity states 𝐵𝑆 ! to recognize. A machine learning classifier 𝐶 is trained to that ef-a) The drone before takeoff.

b) The drone through the right ring.

c) The drone flies towards the left ring. For general matters on the processes associated with BCIs, we refer the reader to the state of the art presented by Nicolas-Alonso et al. [START_REF] Nicolas-Alonso | Brain computer interfaces, a review[END_REF]. A recent and extensive survey on BCI classification techniques is presented by Lotte et al. [START_REF] Lotte | A review of classification algorithms for EEG-based brain-computer interfaces[END_REF].

There is a further distinction between synchronous and asynchronous systems. In synchronous systems, stimuli are always shown to the user at fixed intervals of time during training, given that activations in the brain usually occur with a consistent delay after the stimulus onset. During online use (after training) one must wait for stimulation time, before the BCI generates an output command [START_REF] Lotte | A review of classification algorithms for EEG-based brain-computer interfaces[END_REF]. In an asynchronous system, there is no synchronization of the stimuli during online use and the BCI can be used at any moment without having to wait for the stimulus to begin. The additional difficulty lies in separating the target activity from all the rest of the brain activity [START_REF] Nooh | A review of asynchronous electroencephalogram-based brain computer interface systems[END_REF]. There are many BCI paradigms, however in this work we use Motor Imagery (MI). MI requires users to imagine a motor action (moving their arm left/right, tapping their feet, etc.) without actually moving. This elicits similar activations as though they had moved and can be detected by a BCI. MI is an appropriate modality that can be applied to direct control applications, as the imagined actions match with the directions of the control (left/right hand for turning left/right, tapping feet to go down, etc.) [START_REF] Wolpaw | Brain-computer interfaces for communication and control[END_REF] and thus with the inherent semantics of the control task.

BCIs for Control & Recreational Applications

The first area of application of BCIs was to use them for direct control in HCI systems [START_REF] Wolpaw | Brain-computer interfaces for communication and control[END_REF], but also to combine them in a multimodal setting [START_REF] Nijholt | Turning Shortcomings into Challenges: Brain-Computer Interfaces for Games[END_REF], with more common interaction modalities (e.g. Eye-tracking [START_REF] Kosmyna | Evaluation and Comparison of a Multimodal Combination of BCI Paradigms and Eye Tracking With Affordable Consumer-Grade Hardware in a Gaming Context[END_REF]). There are many practical applications: video games, e.g. World of Warcraft, serious games [START_REF] Kos'myna | Towards a general architecture for a co-learning of brain computer interfaces[END_REF][START_REF] Sung | A development architecture for serious games using BCI (brain computer interface) sensors[END_REF][START_REF] Wang | EEG-Based "Serious" Games Design for Medical Applications[END_REF], robotics & prosthetics [START_REF] Bell | Control of a humanoid robot by a noninvasive brain-computer interface in humans[END_REF][START_REF] Hochberg | Neuronal ensemble control of prosthetic devices by a human with tetraplegia[END_REF]; virtual reality applications [START_REF] Lécuyer | Brain-computer interfaces, virtual reality, and videogames[END_REF][START_REF] Guger | Brain Computer Interface for Virtual Reality Control[END_REF].

There are two types of possible control paradigms: event-based control, where the BCI is used to trigger discrete events in an interface; continuous control, where the BCI is used to directly control the movement of an object or element of the interface (e.g. the movements of a pointer). One particular continuous control application for BCIs of interest for this article is 3D navigation for the purpose of piloting a drone. Royer et al. [START_REF] Royer | EEG control of a virtual helicopter in 3-dimensional space using intelligent control strategies[END_REF] first evaluate the feasibility of the 2D control of an helicopter in a virtual environment, followed by Doud et al. for 3D control [START_REF] Doud | Continuous Three-Dimensional Control of a Virtual Helicopter Using a Motor Imagery Based Brain-Computer Interface[END_REF] with the motivation of achieving a means for telepresence. Finally LaFleur et al. [START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] apply this technique for the 3D control of a real AR.Drone, with good success by using an Operant Conditioning training for 2 months on 5 users. More recently, a practical 2D control BCI system was demonstrated [START_REF] Kosmyna | Bidirectional Feedback in Motor Imagery BCIs: Learn to Control a Drone within 5 Minutes[END_REF][START_REF] Kosmyna | Drone,Your Brain, Ring Course -Accept the Challenge and Prevail! UBICOMP '14 ADJUNCT[END_REF]. The system allows to control an AR.Drone and that is operational within minutes (turning left/right or taking off and landing). This type of system is asynchronous and uses coadaptation techniques between the classifier and the user, which are the main current focus of research efforts that aim at bringing BCIs out of the lab. The system present-ed in this work also falls in the category and we will thus review some of the related work on BCI co-adaptation.

Co-adaptation for Asynchronous BCIs

Scherer et al [START_REF] Scherer | Toward Self-Paced Brain-Computer Communication: Navigation Through Virtual Worlds[END_REF] propose an asynchronous BCI for the control of a virtual environment with three MI classes + a non-control state. They found it difficult to obtain a reliable classification in the asynchronous context. To remediate this problem several approaches have been proposed. One is to add a form of feature selection process to the BCI by performing co-adaptation from the EEG signals, for example the work of [START_REF] Faller | A Co-Adaptive Brain-Computer Interface for End Users with Severe Motor Impairment[END_REF][START_REF] Faller | Autocalibration and recurrent adaptation: Towards a plug and play online ERD-BCI[END_REF] that extends Scherer et al. An initial synchronous calibration phase captures artifact free trials from each class whereby one feature out of six possible features is selected to train a classifier. Subsequently during the online phase, feedback is provided to enable periodical recalibrations when new artifact-free trials become available.

To the contrary of other state of the art approaches, in our system, CLBCI, the coadaptation is driven by the user through a feedback loop rather than by the system through automatic adaptation (we call this co-learning rather than co-adaptation).

Given the BCI also relies on machine learning and the feedback is based on incrementally capturing new training examples for the classifier from the user's signal. As such CLBCI lies at the intersection of BCI co-adaption and interactive machine learning [START_REF] Fails | Interactive Machine Learning[END_REF], where the interaction drives the training of a classifier. The motivation for this approach is to provide a more engaging training period to users, as a long monotonous session of merely following instructions at fixed intervals lead to boredom and to a loss of attention and concentration. This view is inspired by the application of educational science research to BCIs [START_REF] Kos'myna | Towards a general architecture for a co-learning of brain computer interfaces[END_REF] and in improving training protocols for BCIs [START_REF] Lotte | Flaws in current human training protocols for spontaneous Brain-Computer Interfaces: lessons learned from instructional design[END_REF].While other state of the art co-learning approaches tackle the reduction of training time and the minimization of errors the user still remains passive: they do not rely on the ability of the human to learn to use the BCI.

In light of the fact that what we want to evaluate in the experiments is the human learning component, we chose not to make a comparison to these methods in our experiment.

CLBCI System and Architecture

The architecture of the CLBCI system is based on minimum distance classification. The Minimum Distance Classifier (MDC) is a simple classification technique that stems from the pattern recognition literature, where it is used extensively (e.g. image recognition) [START_REF] Duda | Pattern Recognition[END_REF]. It was among the first classifiers applied for BCIs but was mostly supplanted by classifiers such as LDA Linear Discriminant Analysis (LDA) or Support Vector Machine (SVM) [START_REF] Lotte | A review of classification algorithms for EEG-based brain-computer interfaces[END_REF]. The weakness of MDCs is that they are sensitive to noise and when signal sources are not well separated, however they were successfully applied to BCIs in combination with divergences based on Riemannian geometry and was shown to reach state of the art performance [START_REF] Barachant | Multiclass brain-computer interface classification by Riemannian geometry[END_REF]. In this work we use Independent Component Analysis (ICA) in its FastICA implementation to separate signal sources in an unsupervised setting and then apply the distance measures on the identified independent components [START_REF] Hyvärinen | A Fast Fixed-Point Algorithm for Independent Component Analysis[END_REF].

Signal Processing and Acquisition

We applied the following signal processing pipeline in the raw signals in order:

• The Butterworth filter allows selecting the appropriate frequencies for Motor Imagery and discarding unwanted frequencies. We selected a 8-25Hz pass band with a filter of magnitude 4 and with a ripple of 0.5db. • We make 1s epochs from the band passed signals with a .75s overlap (.25s sliding window), we average them 5 by 5 so as to obtain 2 average epochs/s. • Then FastICA is computed on each average epoch in an unsupervised manner in order to separate noise from target activity and make the distance-based classifier's job easier. The FastICA [START_REF] Hyvärinen | A Fast Fixed-Point Algorithm for Independent Component Analysis[END_REF] algorithm projects the signal data in a space where data points are maximally independent, essentially separating task related sources from noise sources and other interference. The difference with other ICA algorithms is that FastICA uses a fast algorithm based on fixed-point calculations. We applied the variant of FastICA with symmetric orthogonalization and using a hyperbolic tangent contrast function. We computed 10 components. We used a GPL Java implementation of the original algorithm as described by Hyvärinen and Oja [START_REF] Hyvärinen | A Fast Fixed-Point Algorithm for Independent Component Analysis[END_REF]. • We then produce average epochs that allow us to smooth the signal and remove some of the variability. The system thus produces an average epoch every second, which is then used for feature extraction and for classification. Thus, the classifier will yield one classification per second. Given that ICA is rather costly to compute, anything less than one second led to sub real-time performance on the machine we performed the processing on (2012 MacBook Air, i7@2.9GHz). • Given the sensitivity to noise and to variability in minimum distance based classification, ICA or other similar processes separate noise source from authentic signals and make it easier for the distance measure to accurately capture relevant differences in EEG patterns. Our classifier only requires minimal training data to start functioning, as our aim was to reduce that training time to a single calibration trial per class. In our system, reference average epochs are captured for each BCI class.

Feature Extraction and Classification

For each classification, we take the current average epoch and compute the distance between this current epoch and the reference signals for each of the class references. The classification outcome is where the distance to the current epoch is the shortest. However our distance measures are not stable under a noisy signal. Right after calibration, there is a single reference signal per class, however when feedback is given, more reference signals are added for each class. When there are several references per class, there will be several distance measurements, in which case the classification will be decided by a majority vote on classification outputs resulting from the individual distance measurements.

Similarly, given that several EEG channels are used, if we use single variable distance measures (as opposed to multivariate measures), we obtain one distance value per channel, which is handled the same way as in the multiple reference setting. In fact, when there are more than one distance measurements, the minimum distance classifier becomes similar to a k nearest neighbors (kNN) classifier. We can also consider using several different distance measures at the same time, much to the same effect. This work extends the work [START_REF] Kosmyna | Adding Human Learning in Brain Computer Interfaces (BCIs): Towards a Practical Control Modality[END_REF]. All the details about the system, its interface and its implementation are available in [START_REF] Kosmyna | Adding Human Learning in Brain Computer Interfaces (BCIs): Towards a Practical Control Modality[END_REF].

Experiments

The objective of the task is of user to fly an AR.Drone and make it pass through large rings continuously in a 5 minutes session (Figure 2). We want to reproduce the experiments of LaFleur et al. [START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] in order to compare the performance of OC (good performance, slow training) to CLBCI. We want to observe how user learning and performance evolve over increasingly long training durations (1 day, 1 week, 1 month) for both approaches to training. We consider that flying a quadcopter, all the more so with a BCI, is an entertaining activity that is appreciated by users as shown by the affluence to previous demos and exhibitions [START_REF] Kosmyna | Bidirectional Feedback in Motor Imagery BCIs: Learn to Control a Drone within 5 Minutes[END_REF][START_REF] Kosmyna | Drone,Your Brain, Ring Course -Accept the Challenge and Prevail! UBICOMP '14 ADJUNCT[END_REF].

Experimental Setup

We used a g.tec USBAmp EEG amplifier2 with 16 electrodes over the motor cortex, with an acquisition rate of 512 Hz. The electrodes were placed over the channels: FCz, C5, C3, C1, Cz, C2, C4, C6, CP5, CP3, CP1, CPz, CP2, CP4, CP6, Pz (Figure 3). We used the TOBI TiA3 signal server on a Win. XP VM and then connected into our java BCI application trough our own Java implementation of the TiA protocol. For left and right turns, the drone was programmed to make a 90 degree turn while moving forward at constant speed (to achieve a smooth turn).

The operator makes the drone takes off at the start of the experiment and land at the end of the experiment. Figure 4 illustrates the commands for the drone4 .

Protocol

We compare user learning (progression in performance over multiple sessions) for both an OC training setting inspired by LaFleur et al [START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] and our CLBCI architecture over three different durations: 1 day, 1 week and 1 month. As such we are not precisely replicating the experiments of LaFleur et al. [START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] as we are considering shorter durations.

With this experiment we want verify the following hypotheses:

• (H.1): For duration of below one month, using CLBCI leads to better task performance compared to OC. • (H.2): Beyond the one-month duration, OC leads to better task performance.

• (H.3): Despite the better performance for OC after a month training, users prefer to train for 5 minutes prior to every time they pilot the drone rather than spend a full month before being able to pilot the drone for the first time.

We made groups of users who follow the same training protocol over three different durations for OC and CLBCI (6 groups). 24 healthy subjects aged between 23 and 44 and novices with BCIs participated in the experiments, and thus we distributed them in groups of 4 for each Duration x System pair: In their paper, for operant conditioning, LaFleur et al. followed a precise training protocol. First users performed 1D cursor tasks for the left/right directions and the top down directions, until they could achieve a performance of at least 80%. Then users performed a 2D cursor task for left, right, top and down combined until 80% performance was achieved. Then their users were performed training sessions on a drone simulator, before actually flying the drone. Their training sessions were spread over 2 months and could last up to 50 minutes. The rationale for choosing 80% is that it is a Fig. 5. Experimental Schedule task performance that clearly lies above the performance and acceptable task performance of 60%. The rationale for 60% being considered as usable is that it is well above the empirical random classification performance by at least 10% (45% for 4 classes, like in this paper, Müller-Putz et al. [START_REF] Müller-Putz | Better than random? A closer look on BCI results[END_REF]).

For our experiment, for the OC condition, we replicate the same type of training sessions where users must complete 1D Left/Right cursor (1D L/R) and Up/Down cursor (1D U/D) sessions, 2D cursor sessions, drone simulator sessions (DS) and a drone piloting session through a ring course (RS).

With CLBCI, instead of following the progressive training paradigm for OC, we ask users to perform a single training session over 4 trials for all classes at once and then follow with a test session. The test session is the phase that directly includes user involvement:

• We explain to the user how to cycle through the three distance measures: so that they can determine the measure that leads to the largest amount of perceived self-control by informally evaluating the resulting classification accuracy. • We offer the possibility of adjusting the decision margin of the classifier in the same fashion to find equilibrium between classification speed and accuracy. • If some of the training trials are faulty (the users report they were distracted or that they moved), we can remove the individual training trails in real-time. Once these settings are determined in the first few sessions, users remember them and start off with a customized BCI.

After the training sessions, the users still perform the simulator sessions (DS) and the ring course sessions (RS). We fixed all session lengths to 15 minutes and the piloting session length to 5 minutes. Within the experimental durations (1 day, 1 week, 1 month) we distributed each session type evenly with equal numbers of sessions, following the order: 1D L/R, 1D U/B, 2D, DS, RS for OC and the interface only session for CLBCI followed by DS and RS. The exact schedule for the experimental sessions is presented in Figure 5.

Evaluation

We evaluate the performance of each user intrinsically like La Fleur et al. through task related measures: Number of rings acquired (number of rings the drone has successfully passed through) -RA; Number of wall collisions, when the drone collides with the walls of the rooms or with objects other than the rings -WC; Number of ring collision, RC; Flight time, the time between ring acquisition -FT; Session length, the total flight time during a session -SL. From the above measurements we can derive several performance indices that will allow us to evaluate different aspects of task performance.

• Average Rings per maximum flight or ARMF, the average number of rings acquired during one session by users. This allows us to measure the absolute task performance without directly considering errors. The higher the ARMF the better. • Average ring acquisition Time or ARAT in ms, the average of FT across a group.

The lower the ARAT, the better the performance. • Percent Total Correct or PTC, the percentage of ring acquisition compared to the sum of the number of ring collisions, the number of wall collisions and the number of ring acquisitions. PTC = RA/(RA+RC + WC). • Percent Valid Correct or PVC, the percentage of Ring Acquisition compared to the sum of the number of wall collisions and ring acquisitions. Thus a valid ring acquisition is a ring acquisition that was not directly preceded by a wall collision. PVC = RA/(RA+ WC). • Percent Partial Correct or PPC. Here we consider that a ring collision is a partial ring acquisition, and thus PPC is the percentage of the sum of the number of ring acquisition and of ring collisions over the sum of the number of ring collisions, wall collisions and ring acquisition. PPC = (RA+RC)/(RA+RC+WC).

BCI Validation

We performed a simple validation that consisted classifying a set of unlabeled signals and comparing them to a set of reference signals for each class using 10-fold cross- 1. 10-fold cross-validated accuracy of our BCI system on two subjects over 10 sessions for Motor Imagery with three different distance measures: Mahalanobis Distance (Maha.), Riemannian Distance (Riem.) and Spearman rank correlation distance (Corr.).

Fig. 6 Averaged IC Activation Map validation. We used the three distance measures that can be used with our system in order to see what is the best distance, if there is one. The analysis was done over the signals of two subjects captured over the course of 10 sessions. We can now look at the cross-validation results from the off-line analysis to validate the BCI system depending on the distance measure used in Table 1. In bold is the best result for each measure and each subject. We did not find that any of the distances had an absolute advantage over the others: it varies from subject to subject. Thus we decided to add a control that allows dynamically switching the distance measure used during the online phase so that it could be easily adapted to each user. Moreover, we compute ICA dipole activation maps for the ICA components that explained 99% of the variance, to check that activations are not due to artifacts (Figure 6). We can see that components 1-2 correspond to left-hand MI, while 4-6 correspond to right-hand MI, although components 5 and 6 seem slightly contaminated by eye movement artifacts, however the cumulative percentage of variance explained for both of the is only 5%.

Results

Given the number of subjects for each condition, we used the Shapiro-Wilk test and found a p value of p=0.234, which means there is insufficient evidence to accept that the null hypothesis of the normality of the distribution of the data is valid. Consequently, we use the Kriskal-Wallis test to measure for significant group effects and then use the Mann-Whitney-U test for post-hoc pairwise analysis with an FDR p value adjustment for multiple comparisons.

Figure 7 shows the results in the form of a bar chart for each of the five indicators. The error bars represent the sample standard variance. The general trend for all three percentage indicators is that CLBCI is better than OC. Overall for training durations of one day and one week CLBCI was better by about 8%. However, OC performs better after a one-month training (~3% difference, 87% for OC and 84 for CLBCI). Although the difference is small, more training (e.g. 1-2 months) could give edge to OC, however, it is likely that performance will not increase significantly. We observe a similar trend for ARAT (lower ARAT for CLBCI for 1D and 1W and then a lower ARAT for OC) and ARMF. A single day of training leads to low PVC and PTC but acceptable PPC for CLBCI. This means that the system is not very usable. After one week of training the performance improves for OC and CLBCI by the same amount, so that they maintain an 8% difference. With above 75% task performance, CLBCI is already usable after a week. We asked our users informally what their impression of the experience was. Most found the experiment and experience interesting and enjoyable: it made them very motivated to perform well. One user said: "It was really a lot of fun! The control was not perfect, but even the part where I bumped into things was quite entertaining and thrilling to say the least." The main concern raised is that the BCI classification rate is slow and makes a smooth movement of the quadcopter difficult to achieve, moreover due to the automatic balancing systems of the drone user felt that the lateral movements of the drone were sometimes sudden, "the drone acted strangely sometimes". Users from the OC groups complained that the training tasks were somewhat boring and that they would have liked to be able to pilot the drone sooner. They found it very difficult to concentrate towards the end of training sessions. On the other hand users from the CLBCI group were quite surprised that they could pilot the drone so quickly and pointed out that it motivated them to go further and to improve their performance.

5

General Public CLBCI Demonstration

The CLBCI system has been demonstrated publicly and tested by over 60 people during several events with the objective of introducing new technologies and interac-tion modalities to users. The session performed by each user was around 10-15 minutes in total (explanation, installation, training, piloting). Most people achieved control and enjoyed themselves greatly even for those that had performed the test several times. Even users who did not achieve control had a lot of fun trying to control it and understand how it works. This attracted media attention and showed that people are inclined to having access to this sort of technology.

Discussion

According to all indicators, CLBCI performs better for training durations up to a month (H1), while the OC training slightly outperforms CLBCI after a month of training (H2). This validated both hypotheses 1 and 2 within the confines of our experimental setting. However, in a broader scope of actual usage by users, we do not have sufficient evidence to suggest whether for longer training periods, the performance of OC is likely to remain better than with a continuous use of CLBCI or whether CLBCI overtakes OC for much longer durations. This means that only a very long-term study in-situ is required to really ascertain the best training practices. CLBCI reaches a usable performance after about a week of use on average, however, by increasing the amount of training for each session when the user starts using the system, we can achieve a better performance for immediate use.

In consequence, we can further hypothesize that over time, if we are satisfied with the classification performance for a particular application, we can reduce the training time proportionally to the increase in performance in order to obtain a constant performance with an increasing comfort use due to the shortening of the training times. In this regard, the integration of implicit error potential detection from other state of the art co-adaptation techniques would be beneficial and complimentary with our own approach. Naturally, we can never go below a single training trial, which amount to a few seconds of training. This point is fundamental because it implies that CLBCI and OC could potentially converge towards the same signal modulation in users. The difference of course lies in the long training period, where CLBCI would allow having a usable system already whereas with OC the user would have to wait until the end of the long period.

In critical application areas (reeducation, prosthesis control, etc.) it would be unacceptable to have anything less than the best achievable performance, and thus a system such as CLBCI would not be robust before it converged to the same level of modulation in users as with OC. However for non critical tasks where user experience, comfort and enjoyment are criteria, then systems like CLBCI are doubtless preferable. Based on informal user feedback from both CLBCI and OC groups, we have some evidence that our third hypothesis (H.3) is true, however a definite proof of its correctness would have required a within-subjects experimental design and a formal questionnaire evaluation, that are incompatible with a between-subjects design aimed at evaluating the temporal evolution of performance.

Limitations and Future Work

The main limitation is signal variability. With CLBCI we need supplemental filtering to minimize noise: our training is shorter than for supervised systems. The processing is costly: we can classify twice per second, which is limiting for continuous control. The limitation on training time constrains us to around four actions for realistically usable systems. Additionally, the low count of electrodes is not ideal for ICA, further studies should have a full 10-20 electrode coverage are required to better perform the validation of the CLBCI system. Building signal databases (database of EEG signals built offline from a large number of subject for a given paradigm that can serve to produce training-free BCIs) [START_REF] Congedo | Brain Invaders": a prototype of an open-source P300-based video game working with the OpenViBE platform[END_REF] may help to obtain BCI systems that require no training.

Moving on from technical limitations, we have discussed that this work is preliminary in the sense that the evaluation is in-vitro (controlled environment) and over a relatively short duration. Experiments in-situ over long periods of time are required in order to truly determine whether the hypothesis of the convergence of CLBCI and OC training is actually possible. Another limitation is the absence of the study of the quantitative user experience through a formal questionnaire. Follow-up in-situ studies should include a detailed questionnaire to precisely gauge how users perceive the training protocols. Finally, recruiting more subjects and a comparison to synchronous supervised systems would be beneficial in future experiments.

Conclusion

We propose a "Co-learning BCI" (CLBCI) that reduces the initial amount of training and makes BCIs more suitable for recreational applications. We replicate an existing experiment where the BCI controls a drone and compare CLBCI to their protocol (OC) over three durations of practice (1 day, 1 week, 1 month). We find that OC works at 80% after a month practice, but the performance is between 60 and 70% any earlier. In a week of practice, CLBCI reaches a performance of around 75%. We conclude that CLBCI is better suited for recreational use. OC should be reserved for users for whom performance is the main concern. The experiment is performed in a controlled environment over a relatively short-term period, we need to carry out further studies in-situ in the long term (1+ years) in order to have a more accurate picture. Given our observations, it is likely that CLBCI (but more generally co-adaptive asynchronous BCIs) and OC eventually converge to the same performance where users have learned to modulate their signals correctly. In summary, the challenges and approaches presented and discussed in this paper show that there are many opportunities for further research. We have identified promising directions and actionable ideas (shorter initial training, co-learning) for researchers in this field. We thereby hope to inspire work that will unlock the full potential of BCIs in everyday applications.

Fig. 1 .

 1 Fig. 1. The experimental environment with two rings four meters apart. The subject is installed in front of a table in between the targets. The drone must pass through the hoops following an "8" trajectory during 5-minute piloting sessions.

Fig. 2 .

 2 Fig. 2. The experimental environment.

Fig. 4 Fig. 3 .

 43 Fig.[START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] The motor imagery drone control scheme

• 1

 1 day training (1.d): (1.d.CLBCI) CLBCI -4 subjects; (1.d.oc) OC -4 subjects; • 1 week training (1.w): (1.w.CLBCI) CLBCI -4 subjects; (1.w.oc) OC -4 subjects; • 1 month training (1.m): (1.m.CLBCI) CLBCI -4 subjects; (1.m.oc) OC -4 subjects.

Fig. 7 .

 7 Fig. 7. The results of the study in the form of the 5 indicators for CLBCI and OC for all three durations (1D = 1 day; 1W = 1 week; 1M = 1 month. Group differences are all significant (ANOVA) as well as pairwise post-hoc tests with a student t-test with p<0.05. The equality of variance and normality preconditions were both met.

Table

	Dist.	Measure	Accuracy Subject A	Accuracy Subject B
	Maha.	71.24% (2.54%)	70.35% (1.42%)
	Riem.	70.45% (1.51%)	71.26% (2.97%)
	Corr.	69.92% (2.10%)	72.34% (1.23%)

http://www.gtec.at/Products/Hardware-and-Accessories/ g.USBamp-Specs-Features

http://sourceforge.net/projects/tools4bci/

The figure is taken from the Minnesotta paper by Lafleur et al. 2012[START_REF] Lafleur | Quadcopter control in three-dimensional space using a noninvasive motor imagery-based brain-computer interface[END_REF] and is made available in the open access article under a Creative Commons Attribution 3.0 license.


Jesús Omar Álvarez Márquez
email: jesus.alvarez-marquez@uni-due.de

Jürgen Ziegler
email: juergen.ziegler@uni-due.de

Preference Elicitation and Negotiation in a Group Recommender System

Keywords: group recommender system, group preference elicitation, negotiation, decision making

We present a novel approach to group recommender systems that better takes into account the social interaction in a group when formulating, discussing and negotiating the features of the item to be jointly selected. Our approach provides discussion support in a collaborative preference elicitation and negotiation process. Individual preferences are continuously aggregated and immediate feedback of the resulting recommendations is provided. We also support the last stage in the decision process when users collectively select the final item from the recommendation set. The prototype hotel recommender Hootle is developed following these concepts and tested in a user study. The results indicate a higher overall satisfaction with the system as well as a higher perceived recommendation quality when compared against a system version where no negotiation was possible. However, they also indicate that the negotiation-based approach may be more suitable for smaller groups, an aspect that will require further research.

Introduction

Over the recent years, recommender systems have proven beneficial in supporting users when selecting or buying items from large sets of alternatives [START_REF] Ricci | Recommender Systems Handbook. Ch. Introduction to Recommender Systems Handbook[END_REF]. Buying something in a virtual shop, deciding which film to watch or planning where to go on holidays can easily become a tedious task when solely relying on manual search and filtering techniques, which may lead to information overload and choice difficulties. Therefore, the importance of recommender systems has increased fast in the last years, being now used widely throughout the in ternet. While the field of recommendations for single users has already been deeply explored, the same cannot be said about group recommender systems. Even though a significant number of group re commenders have been developed in the past years [START_REF] Boratto | State-of-the-art in group recommendation and new approaches for automatic identification of groups[END_REF] [18], th ere is still a range of issues which have not been sufficiently investigated so far.

Most group recommending approaches rely on existing user profiles which are e ither aggregated into a single group profile (model aggregation) before generating group recommendations, or which are used for calculating individual recommend ations that are subsequently aggregated, using a variety of different strategies (reco m-mendation aggregation). However, while sufficient profile information is often not available in the case of single users -either due to a cold start condition, or because users do not want their profile to be stored -this problem is even more pertinent for groups where the likelihood of each user having a stored profile that can be exploited by the recommender is relatively low. This is especially the case for ad-hoc groups who gather spontaneously or who come from different organizational contexts. A further issue is the situational variability of the group members' preferences. This is also a problem in single-user recommending, but is aggravated by the fact that the inherent heterogeneity of preferences in a group may be amplified due to different responses to the situational context. These issues ask for methods that can elicit group preferences on the fly and that can aggregate individual preferences in a manner that best suits the individual users as well as the group as a whole.

Solving the complex trade-off between the degree of satisfaction of individual u sers and the group as a whole is typically attempted by applying one out of set of fixed strategies, such as averaging the satisfaction of all group members or minimizing discomfort for the least satisfied user. However, fixed strategies do not take the d ynamics of group settings and situational needs into account. In particular, the aspect of social interaction when moving towards a joint decision is typically not sufficiently supported in existing group recommenders.

In this paper, we propose a novel approach that tries to approach group recomme ndations from the point of intersection of traditional group recommenders and group decision making theory, allowing users to collaboratively create a preference model (thus addressing collaborative preference elicitation [START_REF] Pu | User-involved preference elicitation for product search and recommender systems[END_REF]), from which recommend ations are generated. In this process, group interaction can happen at two (tightly inte rtwined) stages: (1) users can online discuss and negotiate preferences stated by others, and (2) they can discuss and rate items taken from the recommendation set to arrive at a final consensus decision.

Following the idea that computer-mediated discussion groups have more equal member participation [START_REF] Walther | Computer-mediated communication impersonal, interpersonal, and hyper personal interaction[END_REF], the goal is to avoid unfair situations in which some users might not be satisfied with the items proposed by the system. Our system supports remote online negotiation, although the approach can also be adapted to co -located settings. Each user can specify an individual preference model by freely adding d esired features, using an explicit preference elicitation approach [START_REF] Pommeranz | Designing interfaces for explicit preference elicitation: a user-centered investigation of preference representation and elicitation process[END_REF]. The individual preferences are then aggregated to form the group preference model and to determine an initial set of recommendations. All members' preferences, as well as the group aggregation, are visible to the participants. Most importantly, individual pre ferences can then be negotiated in a system-supported manner: by group discussion, members may thus be able to convince other users to modify their preferences, so the group model changes to better match all members' desires. Recommendations are contin uously calculated and updated when the group preferences change, thus allowing users to immediately see the effect of their actions. Different mechanisms are provided for discussing and reaching an agreement, both for the creation of a group preference model and for the final item selection.

In the following, we first survey related research before presenting the conceptual aspects of our approach. We then describe the prototype implementation Hootle and its user interface design. We report on a user study we p erformed with groups of different sizes and conclude by summarizing our work and outlining future work.

2

Related Work

While the field of recommending items for single users has already received a great deal of attention in recent research, leading to quite effective recommendation met hods, recommender systems for groups are, in comparison, a still less deeply invest igated area. Various group recommender systems have been developed over the recent years, starting from early systems such as MusicFX [START_REF] Anagnost | M usicFX: an arbiter of group preferences for computer supported collaborative workouts[END_REF], a group music recommender, that use different approaches for generating recommendations [START_REF] Boratto | State-of-the-art in group recommendation and new approaches for automatic identification of groups[END_REF][12]. However, there are still many open research questions concerning, for example, the best approach to aggregating individual preferences, techniques for responding to the situ ational needs of the group, or supporting the social interaction processes in the group for converging on a joint decision.

To structure the wide range of different aspects involved in group recommending, [START_REF] Kompan | Group Recommendations: Survey and Perspectives[END_REF] suggest a design space comprising the dimensions preference input (including dynamic aspects), process characteristics, group characteristics, and (presen tation of) output. In the process dimension, an important aspect is how individual, possibly conflicting preferences can be merged to obtain recommendations that best fit the group as a whole. Although different approaches in group recommenders gather and represent users' preferences in different ways, they commonly use one of two schemas [START_REF] Jameson | Recommendation to groups[END_REF]:

Aggregation of item predictions for individual users (prediction aggregation).

This approach assumes that for each item, it is possible to calculate a user's satisfa ction, given the user's profile. Then, using the calculated predictions and making use of some specific aggregation strategy, items are sorted by the group's overall satisfa ction. In [START_REF] Hill | Recommending and evaluating choices in a virtual community of use[END_REF] a video recommender that uses this strategy is described; also Polylens [START_REF] O'connor | Polylens: a recommender system for groups of users[END_REF], a system that suggests movies to small groups of people with similar interests, based on the personal five-star scale ratings from Movielens [START_REF] Herlocker | Evaluating collaborative filtering recommender systems[END_REF] uses this method. Construction of group preference models (model aggregation). Instead of predicting matching items for each user, the system uses information about individual me mbers to create a preference model for the group as a whole. Recommendations are generated by determining those items that best match the group model. The number of possible methods for creating the group's model is even bigger than it is for prediction aggregation strategies. For example, in Let's Browse [START_REF] Lieberman | Let's browse: a collaborative browsing agent[END_REF] the group preference model can be seen as an aggregation of individual preference models. In Intrigue [START_REF] Ardissono | A multi-agent infrastructure for developing personalized web-based systems[END_REF][START_REF] Ardissono | Intrigue: personalized recommendation of tourist attractions for desktop and hand held devices[END_REF] (which recommends sightseeing destinations for heterogeneous groups of tourists) the group preference model is constructed by aggregating preference models of homog eneous subgroups within the main group. MusicFX [START_REF] Anagnost | M usicFX: an arbiter of group preferences for computer supported collaborative workouts[END_REF] chooses background music in a fitness center to accommodate members' preferences, also by merging their individual models. AGReMo [START_REF] Beckmann | Towards a group recommender process model for ad-hoc groups and on-demand recommendations[END_REF] recommends movies to watch in cinemas close to a location for ad-hoc groups of users, creating the group's preference model not only by ind ividual model aggregation but also taking into account some specific group variables (e.g. time, weight of each member's vote). Furthermore, the Travel Decision Forum [START_REF] Jameson | M ore than the sum of its members: challenges for group recommender sy stems[END_REF][START_REF] Jameson | Two methods for enhancing mutual awareness in a group recommender system[END_REF] creates a group preference model that can be discussed and modified by the members themselves, aiming to non-collocated groups who are not able to meet face to face, allowing asynchronous communication.

Regardless of whether the aggregation is made before or after generating reco mmendations, an aggregation method that is appropriate for the specific group characteristics needs to be chosen. There are a number of voting strategies, empirically eva luated in [START_REF]Group modeling: Selecting a sequence of television items to suit a group of viewers[END_REF], that have been used in actual group recommender systems. Some typ ical strategies (and systems using it) are: ─ Average strategy, where the group score for an item is the average rating over all individuals (Intrigue, Travel Decision Forum). ─ Least misery strategy, which scores items depending on the minimal rating it has among group members (Polylens, AGReMo). ─ Average without misery strategy, consisting in rating items using an average function, but discarding those where the user score is under a threshold (MusicFX, CATS [START_REF] Smyth | Case-based group recommendation: Compromising for success[END_REF][START_REF] Smyth | The needs of the many: A case-based group recommender system[END_REF][START_REF] Smyth | Social interaction in the CATS group recommender[END_REF][START_REF] Salamo | CATS: A sy nchronous approach to collaborative group recommendation[END_REF]). ─ Median strategy, which uses the middle value of the group members' ratings (Travel Decision Forum).

On another dimension, the question of preference elicitation has to be solved, which is concerned with how the user-specific preference information needed to generate recommendations is obtained. One approach is to let users rate a number of items in advance and to derive preferences from this set of ratings. AGReMo, for instance, requires group members to create their own model of individual preferences before the group meeting takes place by rating movies that they already saw. In Travel Decision Forum each participant starts with an empty preference form that has to be filled with the desired options, so group members define new preferences for each session. A more interactive approach, although for single user systems, is described in [START_REF] Loepp | Choice-based preference elicitation for collaborative filtering recommender systems[END_REF] which requires users to repeatedly choose between sets of sample items that are selected based on latent factors of a rating matrix. The techniques mentioned also address the cold-start problem when no user profile is available up-front but initially require some effort on the part of the user to develop a sufficiently detailed profile.

However, most preference elicitation techniques do not take group interaction into account. As pointed out in [START_REF] Liu | Exploring personal impact for group recommendation[END_REF], to obtain adequate group recommendations it is not only necessary to model users' individual preferences, but also to understand how a decision among group members is reached. While research on group decision making [START_REF] Saaty | Fundamentals of decision making and priority theory with the analytic hierarchy process[END_REF] is concerned with collaboratively making choices, focusing on the social process and the outcome, these aspects have mostly not been addressed in the development of group recommender systems. The process of group decision making involves a variety of aspects, such as the discussion and evaluation of others' ideas, conflict resolution, and evaluating the different options that have been elaborated. Also interesting for our research is the concept of consensus decision -making [START_REF] Hartnett | Consensus-oriented decision-making: the CODM model for facilitating groups to widespread agreement[END_REF], which seeks for an acceptable resolution for the whole group. Within this context, Group Decision Su pport Systems (GDSS) have emerged, that aim at supporting the various aspects of decision making [START_REF] Berdahl | Groups, technology, and time[END_REF][START_REF] Nunamaker | Lessons from a dozen years of group support systems research: A discussion of lab and field findings[END_REF]. Only few recommender systems attempt to include aspects of group decision theory, for instance, by introducing automated negotiation agents that simulate discussions between members to generate group recommendations [START_REF] Bekkerman | Applying cooperative negot iation methodology to group recommendation problem[END_REF]. However, supporting the entire preference elicitation and negotiation process that may occur when users take recommender-supported decisions is, to our knowledge, not realized by current group recommenders.

Lastly, taking into account the social factor that is involved in group recommendation, one needs to contemplate the question whether a user would be willing to change personal preferences in favor of the group's desires, bringing up the importance of group negotiation. Again in the Travel Decision Forum, users are able to explore other members' preferences, with the possibility to copy them or propose modific ations. The Collaborative Advisory Travel System (CATS) focuses on collocated groups of persons gathered around a multi-touch table. Recommendations are made by collecting critiques (users' feedbacks respecting recommended destinations) that can be discussed face to face, since the system gives visual support to enhance awareness of each other's preferences. The main difference between CATS and the system proposed here is that the former is focused in critiquing items once they have been re commended, while the latter allows negotiation already in the preference elicitation stage.

Preference Elicitation and Negotiation Method

The method developed involves an iterative process of specifying, discussing and negotiating preferences in a remote collaboration setting. Instead of only discussing recommendations produced based on user profiles, interaction among group members is supported right from the beginning of the preference elicitation process. The overall process comprises the following stages which are not meant as sequential steps but which can basically be performed in any order (algorithmic and interface details are described in the next chapter):

1. Users begin by selecting desired features from a set of attributes describing the items available. Since the feature sets may be very large (e.g. cities in our example hotel recommender, users can first search for the features they want and place them in a private area). [START_REF] Ardissono | Intrigue: personalized recommendation of tourist attractions for desktop and hand held devices[END_REF]. By moving a feature to the user's individual preference list, the feature becomes active and is visible to other group members. Several features can be placed and rank ordered according to the relevance they have for the user. [START_REF] Bekkerman | Applying cooperative negot iation methodology to group recommendation problem[END_REF]. The individual feature lists are constantly aggregated in a common, ranked group preference list and the recommendations that best match the current group model are immediately generated and shown to the group. [START_REF] Beckmann | Towards a group recommender process model for ad-hoc groups and on-demand recommendations[END_REF]. Users can discuss preferences stated by others and negotiate them by using a 'petition' function, potentially trading in own preferences for features other users want.

Based on the discussions and negotiations, users may change their preferences which is again immediately reflected in the group model and the resulting recommendations. [START_REF] Boratto | State-of-the-art in group recommendation and new approaches for automatic identification of groups[END_REF]. From the recommendations users can at any time select the item(s) they really like and propose them to the other participants who can accept them or propose altern atives. Also in this stage of the process, discussions are supported by the system.

The closed loop interaction with immediate feedback in the group model and the re commendations increases participants' awareness of others' preferences and the effects their own preference changes have on the group results. The approach also entails aspects of critique-based recommenders since users can criticize or accept proposed features or recommended items. In contrast to fully automated recommender system, users have a higher level of control over the process and can easily adapt it to their current situational needs and context.

Description of the System

To demonstrate our approach we designed and implemented a prototype group recommender system that employs content-based techniques. The system is in principle applicable in a wide range of application areas, such as candidate selection, requirements specification, or leisure activities, as long as it is possible to obtain the properties of the items to be recommended. For demonstration purposes, we chose hotel selection for group travel as application area and use an Expedia dataset consis ting of 151.000 hotel entries with descriptive information. Figure 1 shows a screenshot of the user interface, described as following:

1. Feature exploration. This area consists of a set of defined filters that let users search for specific attributes and a space to store the selected ones. For example, filters could be location, facilities or nearby points of interest.

5.

Recommended

Feature Exploration

2. Individual preferences. Features selected in area 1 can be added here by dragand-drop, meaning that the user wants these features to be present (or excluded) in the recommended items (more details in the section about Individual Preferences).

Users can also rank their preferences to express different levels of importance. 3. Group preferences. A ranked aggregation of all individual preferences is displayed in this area. It is also possible for users to navigate through the preferen ces of other participants here. [START_REF] Beckmann | Towards a group recommender process model for ad-hoc groups and on-demand recommendations[END_REF]. Global chat. In this section, the group can discuss arbitrary questions that come up in the decision process. Requests for preference changes ("petitions") and co mments about specific features can also be displayed here. [START_REF] Boratto | State-of-the-art in group recommendation and new approaches for automatic identification of groups[END_REF]. Recommended items. Here, the items that best match the current group preferences and their relative weight are shown. The list is constantly updated in realtime when users add or change features. [START_REF] Brooke | SUS-A quick and dirty usability scale[END_REF]. Recommendations selected by users. From the recommendations area, users can pick the items they like most, and place them here. This space works as a shared area, so each item added here is visible to all participants.

Feature-based Preference Elicitation

Individual preferences are defined by each group member by selecting features from the exploration area, where they can use different filters to locate them. Later, features can be placed into the user's individual preference space. The system allows to spec ify both positive and negative features. Positive features. A positive property means that a user wants it to be found in the recommendations. Users can specify an order of preference among positive attributes by dragging them to a higher or lower position in the list, which denotes the degree of importance that the user gives to each feature. Multiple features may have the same preference level.

Negative features. Negative properties are those that the user does not want to get as feature of the recommended items. They are placed inside a subspace within the ind ividual area (figure 2), called the veto area. Vetoed attributes have no preference order.

Cost of features.

When users specify a large number of features as preferences, several problems may arise: first, it may be difficult to create meaningful integrated group preferences because the probability that features contradict each other increases, requiring more complex and longer negotiation processes. Second, users may overspecify their preferences making it difficult or impossible to calculate well-matching recommendations. We therefore decided to devise a mechanism that gently pushes users towards only specifying the features they really want.

For this purpose, a method for meas uring the cost of each feature has been implemented. Each attribute has a related cost depending on how restrictive it is (i.e. how many items are left after using it as filter over the database). When a user selects a feature he or she pays for it from a limited budget. Users only have a number of tokens to exchange for attributes so they have to choose which ones are most important. This way, users selecting very restrictive features will only be able to create a small list of preferences as they will cos t more tokens. It is also necessary to remark that the cost for positive attributes differs from the one for negatives. Positive attributes are more expensive the more restrictive they are; for negative features, more restrictiv eness means less cost.

Group Preferences. While creating their individual preference lists, users can immediately see the overall results for the group. Inside the group preference area, an a ggregation of all individual user preferences is displayed. This list is called the group preference list. The aggregation of individual preferences is performed using a variant of the Borda Count method, combined with rules regarding the vetoed attributes.

Borda Count is a voting method in which voters rank options or candidates in order of preference. In standard Borda Count, each option receives a score depending on its rank, and to obtain the aggregated score the points that each voter has given to it are summed up. In the case at hand, not only the rank of each option has been taken into account, but also its cost. When a user chooses to place a relatively expensive (restrictive) feature in the individual preference list, it is fair to think that the user cares more about this specific attribute. The equation used to calculate the aggregated sc ore of an attribute i is presented in [START_REF] Ardissono | A multi-agent infrastructure for developing personalized web-based systems[END_REF], where u is the number of group's members, n is the total number of different attributes used, p ij is the preference value given to the attribute i by the user j, c i is the cost of the attribute i and λ is used to correct the importance of the cost (with λ = 0 the result would be a standard Borda Count voting aggregation).

𝑃𝐴𝑡𝑡 𝑖 = ∑ ( 1 𝑛 (𝑛 -𝑝 𝑖𝑗 )) + 𝜆𝑐 𝑖 𝑛 𝑗=0..𝑢 (1)
Attributes only receive points if users include them in their preferences. Finally, the group preference list is created by calculating the total score for each item and sorting them as usual (figure 3). Vetoing a feature is a strong statement, it means that the person who stated it really does not want items with this feature. It would be desirable to avoid this feature, even if someone else in the group still wants it. Thus, vetoed attributes are removed from the group preference list and will not appear in any of the recommendations.

Generating Recommendations

Based on the aggregated user preferences the system applies a content -based filtering method to generate recommendations (fig. 4). In content-based filtering, items are described by a set of attributes, and each user has a profile of preferences indicating the item properties the user likes. In our case, the individual preference set in a se ssion represents the full user profile, thus, the system is applicable in cold-start situations where no user profile exists yet.

To generate recommendations, group preferences are compared to the items' pro perties in order to find the best matching ones. First, the system removes a ll the items that contain a vetoed attribute. The remaining items receive a score based on how many positive features they match, their total score being the sum of their attributes' values. The value of each attribute comes defined by the Borda Count meth od previously described, so attributes with higher preference levels will give higher score values to the items containing them. For distance attributes (coordinates, regions or points of interest), the value they were assigned by the Borda Count is modified depending on how far an item is from the given feature (closer items obtain higher scores).

If the system would simply present the ten top scored items, it could happen that for some users whose attributes are lower in the group preference list, no good options are returned. Since the main purpose of the system is to provide a negotiation env ironment, it seems necessary to return a well-balanced set of items, in terms of mem-ber satisfaction. For this reason, a subset of items is extracted, within the already found, in a way that for each user there is at least one acceptable option, but giving at the same time importance to the items that satisfy the group as a whole. An item is considered acceptable for a participant when his/her satisfaction level conce rning this option is higher than a given threshold. Satisfaction is calculated taking into account the individual preference model defined by a user, in a similar way an item's group score is calculated, but divided by the maximum points an item could rece ive (that is, when an item contains all the features a user wants). Finally, the selected items are presented to participants in the recommendation area of the screen (5 -Recommended Items in figure 1).

As said before, the system is applicable without requiring the prior availability of stored user profiles which is particularly beneficial in group contexts for the reasons mentioned earlier. However, in principle more complex and longer-term user profiles could be built if past choices were saved for future sessions. If this option was used and is acceptable for users, the interaction effort needed for specifying the desired features could be reduced, just specifying changes in the existing profile, and possibly increasing the precision of the recommendations.

Negotiation

User preferences are typically not a static phenomenon but are influenced by the situational context of the group and the social interaction that takes place within it. Users may also differ in the extent to which they have already formed their objectives at the beginning of the group process. They may react to preferences expressed by ot hers, either accepting or rejecting them. They may also be willing to dispense with a desired feature if someone else in the group accepts one of their other preferences, thus embarking on a negotiation process with other group members. For these re asons, our system provides several functions that specifically support discussion, neg otiation and consensus finding among group members.

Group Profile DB

Set for the group User Communication. Users need the possibility to express their opinions about the dec ision process as a whole as well as about specific preferences stated by others. To support these types of communication, two methods are implemented in the system.

Discussion threads and global chat. Each feature has its own discussion thread, which means that users can access it and say what they think about a specific property, kee ping the comments organized by attribute. A global chat is also available, placed in area 4 displayed in figure 1. The global chat lets participants talk about arbitrary aspects of the current session, and also informs group members about recent updates in specific comment threads.

Petitions.

Petitions are requests such as removing a feature or changing its rank. It is not possible to request the addition of an attribute, as adding a feature to one's ind ividual list is already an implicit petition to the rest of the group: every user wants the others to adopt the same preferences as he/she has, since this would in crease the fit of the recommendations with this user's wishes.

Finding and Resolving Conflicts. Conflicts appear when two or more participants want features that contradict each other. Several mechanism help to resolve such sit uations. First, users can explore the individual preferences of other participants and discuss them if a conflict occurs.

Second, once a set of recommendations is presented, users can access information about each item recommended. Also, those entries in the group preference list tha t are not fulfilled by an item are highlighted in that list. Thus, when a user likes a reco mmendation, he/she can see the preferences that are in conflict with it and try to change the opinion of the members who added them.

Finally, for each recommendation, the calculated grade of satisfaction of each user can be displayed in a spider diagram, so the group may choose items that are more balanced with respect to the members' individual desires (i.e. are less conflictive).

Proposing Items. From the recommendation area, users are able to express their approval for a specific recommended item by placing it into the "recommendations s elected by users" space (area 6 in figure 1). This step shows the group that one user likes a recommendation and proposes it as option. The other participants now can accept it as a good option, reject it or just ignore it, waiting for more proposals to show up.

Repeat and Decide

The "adding features-get recommendations-negotiate" cycle can be repeated several times, narrowing down the recommendations given with each new iteration, until the group reaches agreement. If and when consensus is reached, however, is something that only the group itself is able to decide. As has been said in the previous se ction, users can add items that they like into a shared area, so the others can express their acceptance about it. For some groups, the item to be finally selected may be the one that is accepted by more than fifty percent of the members; in other cases, there may be situations where all users have accepted an item except one who finds it u nsatisfactory. While a fixed group recommendation strategy, for example, a 'least misery' approach that might seem applicable in the latter case, would always try to satisfy user needs in one prescribed manner, we believe that the system cannot generally resolve such decision problems. Although the system provides tools for preference specification, discussion and acceptance measuring, it is up to the users to decide whether a recommendation fits their needs or not and to make the final choice.

Evaluation

To evaluate our approach, we performed a user study with several groups comprising between three and five users. We did not consider larger groups at this point because we believe this group size to be typical for the application domain chosen which is selecting a hotel for a joint leisure or business trip. Also, Hootle, our Web -based prototype implementation of the approach, while still work in progress, is stable enough to support this group size but still has to be tested for larger-scale trials. The main objectives of this study were to determine the usability of the approach and the quality of the resulting recommendations, as well as, more specifically, to analyze the impact of the cooperative preference elicitation and negotiation tools developed.

Setting and Experimental Tasks

To assess whether the preference elicitation, negotiation and recommendation met hods developed benefit group decision processes, we tested two different versions of the system where one served as baseline for comparison. While one system version provided the full set of functions described including group discussion support (hereafter version D -Discussion), we restricted the second version to specifying preferences and calculating recommendations (version ND -No Discussion), similar to a conventional group recommender system, but still offering the possibility to specify preferences in an ad-hoc manner without using existing user profiles. We decided against using an existing alternative group recommender for comparison because the systems would have differed in too many aspects, making it difficult to pinpoint the specific benefits of the proposed innovations. In both cases, we make use of a hotel database provided by Expedia with 151,000 entries. For each hotel, a full description and a set of attributes, including property and room amenities (within a total of 360 possibilities), locations (258,426) and points of interest nearby (94,512) was available. We deliberately decided to focus the negotiation and decision process on the objective properties of the items, excluding price information which would have opened up additional questions concerning economic concerns and behavior in the test groups. This aspect, however, will be subject of future research.

We prepared two types of task scenarios with different levels of complexity:

 In an 'introductory' task, the group was instructed to select a hotel knowing b eforehand some common, desired attributes, as well as the location of the hotel. This task also served as a training session for the application, to allow participants to explore the functions and possibilities the system supplies . Two scenarios for this task were presented: ─ Your group will be participating at a conference in Berlin. As the conference always provides lunch and dinner, you just need to find a hotel including brea kfast. Your conference takes place near the Brandenburg Gate. ─ Your group wants to enjoy some days on the beach. You already decided to go to an apartment, as you want to prepare meals on your own. Everyone loves Spain so you also decided to go to Marbella.  In the 'open' task which was always performed after the introductory task, only unspecific instructions were given to the group such as "Find a place to stay during summer vacation". The possible scenarios were: ─ It is summertime. You and your friends really need to get out of the daily routine. Discuss where to stay. ─ Your group wants to do some kind of city trip. Where are you going to?

To avoid the problem that in a test situation, participants do not bring with them the objectives and preferences they would have in a real-life decision situation, or might comply too quickly with the wishes of other participants, we tried to artificially induce different backgrounds and objectives for each group member. For this purpose, we created a set of role cards for the second task, depending on the scenario used. With this method, we expected to generate conflicts and discussion when randomly distributing the role cards among group's members. As an example, the role cards for the first scenario in task 2 were (abbreviated here):

1. You're a sport addict. You like to eat healthy and don't trust in hotel food. You hate giant hotels and prefer small pensions or camping sites. 2. You're allergic to nearly everything. Vacation at a camping site would be like a death sentence to you. You prefer the pool over the sea. You don't want to do anything so you prefer all inclusive. 3. You like to go for long hikes. You're fascinated by mountains. You don't want to cook but you won't be there during the day so you just need breakfast and dinner. [START_REF] Beckmann | Towards a group recommender process model for ad-hoc groups and on-demand recommendations[END_REF]. You're into cultural things. If you go on vacation, you want to see things. You also like to go out for dinner so breakfast only would totally fit your needs. [START_REF] Boratto | State-of-the-art in group recommendation and new approaches for automatic identification of groups[END_REF]. You like to party. As you won't be able to prepare your own food, there should be someone who helps you with this. More important is the location of your hotel. Nobody wants to walk for an eternity to go clubbing.

Method

A total of 48 students were recruited as participants (5 male, 43 female, average age of 20.94, σ 5.018), distributed in groups of different sizes: 4 groups of 3 persons (12), 4 groups of 4 persons ( 16) and 4 groups of 5 persons [START_REF] Smyth | Case-based group recommendation: Compromising for success[END_REF]. Two groups of each size ran a full version of the system (D), while the other two groups tested the version without negotiation support (ND). Since the system is Web -based, all users were provided with a normal desktop computer with a display screen of 21" and running the same browser. They sat in a large lab room but were separated from each other and instructed to only communicate via the means provided by the system. Each group first received a brief introduction to the system which was dependent on whether the negotiation support was turned on or off for the group. After a brief trial, they were asked to work on the two decision tasks, always in the order introductory taskopen task. Before beginning the second task, they all received randomly one of the role cards.

For the groups using version D, a task was considered complete when they reached consensus about their preferred hotel or when they decided that it was not possible to find agreement. Since the groups with version ND were not able to communicate at all, their job consisted in defining their own preference model and, when the whole group had done this, each user separately selected a hotel from the resulting set of recommendations.

The first task including the explanation of the system was limited to a maximum of 40 minutes. As the explanation was no longer necessary, the second task, although more complex, should also be completed during this time.

After completing both tasks, participants were asked to fill in a questionnaire regarding aspects such as the quality of the recommendations or the ease -of-use of the system, using a 1-5 scale. The questionnaire comprised the SUS items [START_REF] Brooke | SUS-A quick and dirty usability scale[END_REF] to compare the system against a well-established baseline as well as items from two recommender-specific assessment instruments (User experience of recommender systems [START_REF] Knijnenburg | Explaining the user experience of recommender systems[END_REF] and ResQue [START_REF] Pu | A user-centric evaluation framework for recommender systems[END_REF]). The recommender-specific items were measuring mainly the constructs user-perceived recommendation quality, perceived system effectiveness, interface adequacy, and ease of use.

Results and Discussion

All tasks were finished within the allotted time. The D an ND groups differ on a considerable number of criteria. The members in ND groups were not able to choose the same hotel in a single instance. In two of these cases, some users couldn't even find a hotel that they liked when realizing the open tas k. On the other hand, all groups with version D were able to choose one unique hotel in both tasks, despite starting the process with strongly different individual preferences. To achieve this joint decision, users had to iterate several times through the "adding features-get recommendationsnegotiate" cycle, as well as to renounce some desired features due to the influence exerted by other members through discussions and petitions.

In terms of overall usability, both system versions received a SUS score wh ich can be considered as borderline good with no differences between the two systems (ND = 68, D = 69). We performed a 2x3 ANOVA with system version and group size as independent variables and questionnaire item scores as dependent variables. Most item responses did not show significant differences between the two system versions which may be due to the limited number of groups tested. In Table 1, we list some of the results that were significant at a .05 level. Users in the discussion condition were overall more satisfied with the system, are more likely to recommend it to others and would be willing to use the system again and also more frequently. Also, the accuracy of the recommendations was rated higher in the discussion groups. While these results speak in favour of the discussion version, there appears to be an interesting interaction effect between system versions and group size. Generally, satisfaction and willingness to use and recommend the system tend to be higher for the small groups than the large groups when discussion is available. Concerning recommendation quality, the largest group had the highest ratings in the no-discussion condition while this is reversed in the discussion condition where the smallest group had the highest rating. This pic ture is somewhat blurred by the fact that the medium-sized groups (4 persons) had the largest variability so there is no clear relation between group size and these variables.

For the remaining questionnaire items (which we cannot report here fully due to space limitations) there is a tendency in favour of the discussion version both in the items related to usability and acceptance of the system as well as concerning the fit of the recommendations and the ease with which a matching hotel could be found.

The time needed to come to a decision differed significantly between the introdu ctory task and open task (13,500 vs. 26,333, p=0.05). Results concerning negotiation behavior are listed in Table 2: both individual changes and number of petitions increase with group size. In relation with Table 1, it may be concluded that users in small groups are generally more satisfied because they were able to select more pre ferences for themselves and made less changes in their individual lists (keeping their initial wishes). Discussion: The results of this study can only give a first indication of how well the proposed approach works in comparison to other techniques and in different group contexts. We can see significant advantages for our approach of including discussion and negotiation features in a group recommender in some relevant items, as well as a tendency in favour of the system in the majority of other items. However, it appears that the system may be more useful in small groups. This may be due to several fa ctors: first, as larger groups require more communication and negotiation to obtain an acceptable end results, this may increase the complexity of the task and the interaction effort. This may be true for other group decision making systems as well but will require further research. A second factor may be artificially created by the experimental method used. Since users were instructed to play the roles described in their respective role cards, the diversity of preferences increased with group size, possibly making it more difficult to make sense of the diverse standpoints and to lead the neg otiation towards a joint group decision. This may not be the case in typical real world settings where group members' viewpoints may be more homogenous due to the prior history of the group. Also, the role card method can only be taken as an approximation of a real situation. In any case, the observed tendencies raise interesting general questions concerning test scenarios for evaluating group recommender systems.

6

Conclusions and Outlook

We have presented a novel approach to group recommending that provides more interactive control over the recommendation process than typical group recommenders and that does not require the prior availability of the group members' preference profiles, taking into consideration cold-start situations and potential privacy concerns.

Most importantly, the method provides discussion and negotiation support in a co llaborative preference elicitation and negotiation process. Individual preferences are aggregated in a group preference profile which is immediately updated when users change preferred features or their relevance level. Also, the resulting recommend ations are continuously recalculated when group preferences change, and are always visible to the whole group. Since producing recommendations constitutes just an intermediate step in the group decision process, we also support group interaction in the final decision steps where the group needs to find consensus about the item finally selected.

The proposed technique provides much higher flexibility and responsiveness to situational needs than the fixed strategies typically used in group recommenders. While this research has focused on specifying preferences in an ad -hoc fashion, the method can easily be extended by storing and re-using user profiles, thus reducing interaction effort to simply adapting an existing profile. Since the preferences of other users and resulting group preferences as well as the recommendations that match this profile are always visible, participants' awareness of individual and group views and of the effects of their preference settings is increased.

Based on these concepts, we developed the prototype hotel recommender Hootle and tested it in a user study. The results indicate a higher o verall satisfaction with the system as well as a higher perceived recommendation quality when compared against a system version where no discussion was possible. However, we also saw an indic ation of an interaction effect between group size and the two sys tem versions which suggests that the negotiation-based approach may be more suitable for smaller groups. Whether this effect is due to the increased communication effort in larger groups, or may be dependent on the experimental scenarios used in the study is still an open question.

In future work, we aim at investigating the effects of group size more deeply and at optimizing the system to better scale for larger groups. A further work item is to co nsider alternative aggregation functions that may perform better than the Borda Count variant currently used. Finally, we aim at further improving the user experience with respect to the discussion and decision making features implemented. Also, more e xtensive empirical studies are planned, addressing also domain s other than hotel selection.

Fig. 1 .

 1 Fig. 1. Areas of the interface.

Fig. 2 .

 2 Fig. 2. Example of preference areas belonging to two different users. The ordered list represents the positive (desired) attributes, while the area at the bottom contains the negative (vetoed) ones. The cost of each attribute can be found at the top -left corner.

Fig. 3 .

 3 Fig. 3. Resulting preference setting for the group, using the individual lists shown at figure 2.

Fig. 4 .

 4 Fig. 4. Scheme of the filtering process.

Table 1 .

 1 Results of the questionnaire (all the D/ND differences p>0.05, effects of group size were significant).

	S ystem version			No discussion			Discussion
	Group Size		3	4	5	Avg.	3	4	5	Avg.
	Overall	m	3.40	3.00	3.70	3.39	4.33	4.00	3.60	3.92
	satisfaction	σ	0.54	1.20	0.48	0.83	0.51	0.53	0.96	0.77
	Would	m	3.20	2.38	3.30	2.96	3.50	3.25	3.30	3.33
	recommend it	σ	1.30	1.06	0.67	1.02	0.83	0.70	1.06	0.86
	Would use it again	m σ	2.40 0.89	2.50 0.92	3.10 1.10	2.74 1.01	3.17 0.75	3.13 0.99	3.00 0.66	3.08 0.77
	Would use it	m	1.60	1.88	2.30	2.00	2.67	2.75	2.70	2.71
	frequently	σ	0.54	0.64	0.67	0.67	0.81	1.04	0.94	0.90
	Recommendations	m	3.20	3.38	3.80	3.52	4.33	3.38	4.00	3.88
	were well chosen	σ	0.83	0.74	0.78	0.79	0.51	0.74	0.47	0.68

Table 2 .

 2 Objective results (lower and upper bounds at 95% confidence interval).

		3 Participants	4 Participants	5 Participants
		m	LB	UB	m	LB	UB	m	LB	UB
	Time	21	31	10,9	17,2	7,23	27,2	21,5	11,4	31,5
	Pref. Sel./Part.	3	2,37	3,62	2,31	1,76	2,85	2,80	2,31	3,28
	Ind. Changes/Part.	7,33	1,79	12,8	10,1	4,64	15,7	13,1	7,61	18,6