actividades colaborativas mlear

8/12/2019 actividades colaborativas mlear

1/8

Recommending Activities in Collaborative M-Learning 1

Estefana Martn, Nuria Andueza, Rosa M. Carro, Pilar Rodrguez

Escuela Politcnica Superior, Universidad Autnoma de Madrid28049 Madrid, Spain

[email protected], [email protected],{Rosa.Carro, Pilar.Rodriguez}@uam.es

Abstract. In this paper, the recommendation process carried out in a collabora-

tive mobile learning environment is presented. Its main aim is to recommendthe most suitable activities to be proposed to a specific user at a certain time depending on his/her personal features, previous actions and current context (loca-tion, spare time, available devices). The recommendation process also decideswhether it is appropriate to alert the user about the availability of the recom-mended activities or, otherwise, the user should not be disturbed at that time.This process is based on rule processing and log analysis. Its basis, illustrated

by an example of a specific scenario, is presented.

1 Motivation

The widespread development of mobile and wireless technologies is leading to thecreation of systems to support the realization of activities from any place at any time.People spend a lot of time working and travelling nowadays and time has become avaluable good. These facts motivate the appearance of web-based applications thatfacilitate an agile and flexible realization of activities in different situations. In thecontext of learning, mobile learning (m-learning) applications have also been devel-oped. M-learning has been defined as e-learning through mobile and handheld devicesusing wireless transmission [1]. The fact that different learners have distinct needs,

preferences or personal features has been considered with adaptation [2][3] and rec-ommendation [4] purposes. In the context of m-learning, the contents also need to beadapted to different devices [5]. A classification of the characteristics that can be usedwith adaptation purposes in mobile learning environments is presented in [6].

In this framework, we aim to recommend users with the most suitable activities to be tackled at a certain time, depending on their personal features, previous actions andcurrent context (location, spare time, available devices). The recommendation processshould also decide whether it is appropriate to alert the user about the availability ofrecommended activities or, otherwise, the user should not be disturbed at that time.

The rest of the paper is organised as follows: Section 2 presents the main goals ofthis work and a sample scenario. Section 3 describes the recommendation process andits functioning for that scenario, and section 4 describes conclusions and future work.

1 This work is funded by the Spanish Ministry of Science and Education, proj. TIN2004-03140


2/8

2 Sample Scenario and Main Goals

In order to illustrate the functioning of the recommendation process, a sample sce-nario is provided. In this scenario, two users are considered: Ann and John. Both ofthem are students of Informatics and partners for laboratory work. Both are novicestudents (they have no previous knowledge). Regarding the active/passive dimension[7], Anns learning style is active while Johns is passive. They both use to connect toa learning system. Some activities defined in this system are:

A: Lab work to be done collaboratively. It is composed by different subactivities. B: Meeting between the members of a group to plan collaborative work. C: Collaborative elaboration of a solution for a given problem.

D: Writing a report. E: Solving a free text answer exercise individually. F: Reviewing already studied materials. G: Sending messages.

The relationships between these activities have been established in different waysdepending on the users the activities are intended to. In the case of the composedactivity A, it will be split in different ways for novice and advanced students. Whenaccessing A, novice students will be presented with activities B, C and D, in this order(direct guidance). Advanced students will be presented only with C and D, and theywill be allowed to tackle them in any order (free guidance).

Today, John is sat on the grass at the university campus and sends a message toAnn through his PDA 15 minutes before going to the laboratory. The system recom-mends him to review some contents, but John disconnects. Ann is travelling to theuniversity. Her trip is around 45 minutes long. She switches her laptop on to checkwhat she can do during the trip. The system sends Johns message to her and alsorecommends her to review already learned contents (activity F). As her partner John isnot connected now, she is not proposed with the synchronous collaborative activity B.Afterwards, when Ann and John connect to the system from different laboratories,they are informed about the possibility of accomplishing the synchronous activity B.

Our main goal is to recommend the most suitable activities to be tackled by eachuser in an m-learning environment according to their specific context (physical loca-tion, spare time and available devices), personal features (learning style, expertise,etc.) and previous actions (activities done, results obtained, etc.). The recommendingsystem should also be able to decide whether the users should be alerted intrusivelyabout the availability of a new recommendation. More specifically, we aim to:

Provide general recommendations related to the suitability of certain types of ac-tivities in specific contexts.

Include/exclude activities for different types of students and propose each activityat the most appropriate time for each of them.

Adapt the navigational guidance offered (direct, free or alternative) to differenttypes of students when tackling a set of related activities.

Exclude activities with specific requirements related to the users context or per-sonal features in case that these conditions are not satisfied.


3/8

Manage groups and collaborative activities, so that collaborative synchronousactivities are proposed to users only if they are connected at the same time.

Alert the users about new recommended activities intrusively only when it is con-sidered convenient to interrupt them, according to their context.

Use information about previous interactions of the students in case that no instruc-tions are given about a certain activity, in order to decide whether the studentshould be interrupted to be informed about new recommendations.

3 The Recommendation Process

The recommendation process is divided in two phases: i) selection of the most suit-able activities to be accomplished by a user in a specific context, and ii) decisionabout the convenience of alerting him intrusively. In the first phase, information aboutthe activities, the relationships between them, the suitability of some types of them incertain contexts and the specific requirements of specific activities (if any) is proc-essed. This information is represented by means of rules, which are described in sec-tion 3.2.

Concerning the types of activities to be supported, users can accomplish both indi-vidual and collaborative activities such as studying theory, learning from exam-

ples/simulations, solving exercises, doing lab work, or discussing about topics. Othertypes of activities are generated on the fly, such as sending/receiving messages orfiles, or asking/receiving tutoring. Each activity may include conditions about itsavailability depending on any information about users and groups.

The information about the users to be considered with recommendation purposes(the users features, actions and context) constitutes the user model. The informationabout the groups is stored in the group model and contains, for each group, data aboutits members, the activities in which they are involved, the results of the activitiesaccomplished, and the users opinions about previous collaborations. The informationabout the users actions is also used for giving recommendations according to theusers previous behaviour in similar situations. In cases where not enough previousinformation about a user is available, information about similar users can be used.

During the recommendation process, each activity has a state, which is updatedduring the process: recommended (all conditions are satisfied), available but not rec-ommended (conditions related to the users context are not satisfied) and unavailable(non-contextual conditions are not satisfied). An annotated list of activities is gener-ated dynamically. Annotations are made according to the traffic light metaphor [8]:

the recommended activities are marked in green colour; yellow is used for available but not recommended activities; and red is used for unavailable activities.Once the activities have been annotated, the alerting module is in charge of decid-

ing whether the user should be intrusively alerted about the recommendations or,otherwise, the recommendations should be stored and made available for the userwhen he/she asks for it. In order to make this decision, alerting rules are processedand, in case that no rule is triggered, a statistical analysis is done to obtain informationabout what resulted better for the same or similar users in similar contexts. The phasesof the process mentioned above are described in detail next.


4/8

3.1 Main Phases of the Recommendation Process

With the aim of exemplifying each phase of the recommendation process, Ann andJohns example will be used. Recommendations will be done to Ann when travelling

by train, and to John when having a rest outside of the university.

The Activity Recommendation PhaseDuring this phase, the availability and suitability of activities for a certain user in a

particular context is decided according to the characteristics and context of the user.This phase is structured in three steps: initial recommendations based on structuralrules, context-based recommendations, based on a filtering process, and recommenda-tion refinement, based on specific activity conditions (see figure 1).

ACTIVITY RECOMMENDATION

Individual

recommendation

Context-based

recommendation

Structure-based

recommendationGE F

D

C

BA

Initial

recommend.

GE F

D

C

BA

Filtered

recommend.

GE F

D

C

BAFinal

recommend.

USER MODEL

ACTIVITIES

STRUCTURAL RULES

GENERAL FILTERS

INDIVIDUALCONDITIONS

B D EA FC G

Cond Cond

D

C

BA A B

D

Novice Advanced

AND ANY

B E

GROUP MODEL

Fig. 1. Activity recommendation

Initial recommendations.The first step concerns the selection of activities depending on their relationships, aswell as on their requirements and on the navigational guidance for each set of activi-ties (direct guidance, free navigation or alternative paths), which can be different foreach type of student. For this initial selection, structural rules [9] are processed. Theyindicate the way in which each activity is split in sub-activities for each type of user,

and contains information about the curricula adaptation. The relationships betweenactivities and the navigational guidance to be offered can be established in differentways for different types of users, by means of rules with distinct activation conditions.During this phase, the rule conditions are compared to the information about the user,and if a rule has no conditions or its conditions are satisfied, it is triggered and thecorresponding activities are added to the list of available activities. After this phase, afirst set of available activities is obtained. It constitutes the initial recommendation.

In our example, A is split in different ways for novice and advanced students, asshown in (1). When accessing A, novice students will be presented with B, C and D,


5/8

in this order, as indicated by R 1. Therefore, they will be guided directly to B. How-ever, R 2 indicates that the advanced students will be presented only with activities Cand D, and they will be allowed to tackle them in any order (free guidance).

R 1: [knowledge = novice] A B + C + D (direct)R 2: [knowledge = advanced] A C + D (free)

(1)

In the scenario, as Ann and John are novice students, R 1 is triggered and B is anno-tated in green and added to the initial list of recommended activities for both of them.Since no structural rules are given for E, F and G, they are also added to the list.

Context-based filteringIn this second phase, the initial list of recommended activities is filtered according tothe information about the suitability of each type of activity for the context in whichthe user is. This information is made explicit in context-based rules, which indicatewhich types of activities are recommended (or not) for certain types of users accord-ing to their context. Context-based filtering consists of triggering the correspondingrules for each user and updating the annotated list of activities accordingly.

In our example, it was considered desirable to propose review, theory and individ-ual exercise activities to active students if they have more than 15 minutes left and areoutside the university or home. However, it is considered inappropriate to propose anindividual exercise to passive students if they are outside but have less than 20 min-utes left. These decisions are specified by the rules presented in (2).

R 3: [lstyle=active, time>15, place=outside] review, theory, ind_exerciseR 4: [lstyle=passive, time


6/8

R 5 : [knowledge=novice, time>60] ER 6 : [knowledge=advanced, time>30] E

(3)

Therefore, according to R 5, the activity E is not recommended to Ann in her currentcontext (she has not enough available time). Therefore, E is annotated in yellow, asavailable but not recommended at that time. Concerning implicit conditions, as Brequires the members of the same group to be connected synchronously and John isnot connected when Ann enters the system, B is marked in red for Ann. The final listof recommended activities for Ann when travelling by train contains: B, C and D inred, since they are not available now; E in yellow, since it is available but not recom-mended; and F and G in green, to be recommended to Ann. Regarding John, he isrecommended to get involved in F (rules R 1, R 4 and R 5).

The Alerting PhaseAt this phase it is decided, for each activity of the annotated list generated during the

previous phase, if the user should be immediately informed about the recommenda-tion or, otherwise, if the activity should be stored in the list of pending activities, sothat the user is not disturbed at that time but can access this information afterwards.This phase consists of two steps: rule-based alerting and log analysis (see figure 2).

ALERTING

Ruleprocessing

Loganalysis

HISTORICAL LOGFeatures ActionsContext

Alerts Checking

FG

ALERTING

USER MODEL

GROUP MODEL

GE FDCBA Alerts

Pendingactivities

F

G

EB

Fig. 2. The alerting phase

Rule-based AlertingIn this step, decisions about the convenience of interrupting a user to inform him/herabout the recommended activities are taken. With the aim of configuring the alertingservice, alerting rules must be specified. They may have conditions related to users oractivities and they can be grouped according to the nature of their activation condi-tion, which gives rise to different sets of rules. Each set constitutes an alerting filter.Therefore, it is possible to establish different types of filters by means of different setsof rules. Regarding the rule processing, for each recommended activity, if a rule gives


7/8

information about the (un)convenience of alerting the user about it, the activity isadded to the list of alerts or directly kept in the list of pending activities, respectively.

The result of this phase is the annotated list of activities obtained during the rec-ommending-activity phase, along with information about the convenience (or incon-venience) of alerting the user intrusively about each of them. The Log Analysis mod-ule takes the decision if no information is found about it in the alerting rules.

Some of the rules that give rise to the configuration of the alerting service for ourexample are presented in (4). As it can be seen, in our example the users will bealerted about the availability of urgent activities, messages or reminding. On the con-trary, users will not be alerted intrusively if they do not want anyone to disturb them,if they are at the university attending a lecture of if they are taking a practical class inthe lab. In these cases, the activity must be stored in the list of pending activities.

R 7: C_Conection [state = not_connected or state = not_disturb] STORER 8: C_Conection [urgency = urgent] ALERTR 9: C_Type [type = message or type = remind_later] ALERTR 10: C_Location [location = uni_class] STORER 11: C_Location [location = uni_labo AND agenda = class] STORE

(4)

In our scenario, the recommended activities for Ann are F and G. As G is a mes-sage, rule R 9 is activated, and the message is sent directly to her. Given that no infor-mation is provided for F (review activity), the log analysis module can take charge ofthe final decision for both Ann and John.

Log Analysis.

Finally, the previous actions of the users are analysed in order to decide whether, in aspecific situation, it is appropriate to alert the user about the availability of certainactivities. The actions of the user in similar previous situations are considered in orderto take the decision about the convenience of interrupting the user. If this informationis not enough or does not exist (the user was not in similar situations before), theanalysis is done with respect to what similar users did in these cases.

In our example, no decision has been taken concerning the recommendation of F toAnn. Therefore, F is processed. Let us suppose that Ann uses to use her spare time forreviewing already learned topics when travelling. The result of the statistical analysissays that more than 60% of the times when Ann was proposed to review topics insimilar situations she did it. Therefore, Ann is informed about the recommendation ofactivity F. With respect to John, no information is available, so he is suggested thisactivity too. He does not engage in the activity, what is stored for future decisions.

4 Conclusions and Future Work

We have developed a recommendation process that i) selects the most suitable learn-ing activities for each user taken into account his/her personal features, characteristicsof groups and the current context and ii) informs the user about new recommendationseither intrusively or non intrusively.


8/8

The modularization of the recommended process makes it possible the specifica-tion of adaptation capabilities in a flexible and configurable way. It is possible to givesuggestions at a general level (based on the relationships between activities or on theirtype) and at an activity level (based on their specific requirements), by means of dif-ferent types of rules. Thus, it is possible to decide which type of recommendationswill be supported, by providing the corresponding type of rules.

The alerting mechanism is also configurable: instructions about in which cases theusers should be disturbed to be informed about new recommendations can be given.Alerting rules support the specification of these criteria, which can be different for thesame type of users depending on their context and also for distinct types of users inthe same context. If no instructions are given (which is also feasible), a log analysiswill help to determine the convenience of alerting the user intrusively or not, based onthe previous actions of the users (or similar users) in analogous contexts. This loganalysis could be applied not only for deciding about the convenience of alerting theusers about the availability of activities, but also for recommending activities depend-ing on what the users did in previous similar situations. In such a way, the recommen-dation process would be enriched. Future work concerns testing the recommendation

process to check its suitability and exploring the possible use of log analysis in theactivity recommendation phase.

References

1. Ktoridou, D., Eteokleous, N.: Adaptive m-learning: technological and pedagogical aspects to be considered in Cyprus tertiary education. In: Recent Research Developments in Learning

Technologies. Badajoz, Spain, (2005) 676-6832. Brusilovsky, P.: Adaptive hypermedia. In: Kobsa, A. (eds.): User Modelling and UserAdapted Interaction, Vol. 11, 1/2 (2001) 87-110

3. Alfonseca, E., Carro, R.M., Martn, E., Ortigosa, A., Paredes, P.: The Impact of LearningStyles on Student Grouping for Collaborative Learning: A case study. User Modeling andUser-Adapted Interaction. Special Issue: User Modelling to Support Groups, Communitiesand Collaboration. Kluwer Academic Publishers. Accepted for publication.

4. Zaine, O.R.: Building a Recommender Agent for e-Learning Systems. Proceedings of Inter-national Conference on Computers in Education (ICCE02), (2002)

5. Zimmermann, A., Specht, M., Lorenz, A.: Personalization and Context Management. UserModeling and User-Adapted Interaction, 15, Springer-Verlag, (2005), 275-302

6. Jppinen, A., Nummela, J., Vainio, T., Ahonen, M.: Adaptive Mobile Learning Systems -The Essential Questions from the Design Perspective. Proceedings of MLearn 2004, Roma,Italy, (2004), 109-112

7. Felder, R.M., Silverman, L.K.: Learning Styles and Teaching Styles in Engineering Educa-tion. Engineering Education, 78 (1988).

8. Schwarz E., Brusilovsky P., Weber G.: World-wide intelligent textbooks. In: Carlson, P.,and Makedon, F. (eds.): Proceedings of ED-TELEKOM 96 - World Conference on Educa-tional Telecommunications, AACE, (1996), 302-307

9. Carro, R.M., Ortigosa, A., Schlichter, J.: A Rule-based Formalism for Describing Collabora-tive Adaptive Courses. In: Palade, V., Howlett, R.J. and Jai, L.C. (eds.): Knowledge-BasedIntelligent Information and Engineering Systems. Lecture Notes in Artificial Intelligence2774, Springer-Verlag (2003), 252259.

Documents

actividades colaborativas mlear