Incremental Bilateral Preference Stable Planning over Event Based Social Networks

. In recent years, Event Based Social Networks (EBSNs) appear in people’s daily life and are becoming increasing popular. In EBSNs, one typical task is to make personalized plans for users. Existing studies only consider the preference of users. They make plans by selectinginterestingeventsforusers.However,fororganizersofevents,theyalsowouldlikemorehigh-qualityuserstoparticipatein theirevents,whichmaymaketheeventsmoreexciting.Existingstudiesareuser-centeredandignoretherequirementoforganizers. Whatismore,organizersareallowedtomodifytheireventsdynamicallybeforetheyareheld.Theplatformsshouldbeableto dynamicallyadjusttheschedulesofusers.Therefore,weidentifyanewIncrementalBilateralPreferenceStablePlanning(IBPSP) problemoverEBSNsandproposeseveralsolutionstodealwithdifferentsituations.Weconductextensiveexperimentstoverify theefficiencyandeffectivenessoftheproposedalgorithms.


Introduction
In recent years, Event Based Social Networks (EBSNs) [1] have experienced rapid development and attracted much attention from both industry and academia fields.EBSNs, such as Meetup (https://www.meetup.com/)and Plancast (http://plancast.com/),link the online social groups and the offline events.Taken Meetup(https://www.meetup.com/) as an example, it has attracted more than 16 million users with more than 300 thousand events held each month.
In EBSNs, one typical task is to select suitable events and make personalized plans for users to participate in according to the labels that users select as their interested points.Therefore, we can evaluate the interest of users to events based on the similarity of labels of users and events, called utility score [2][3][4][5][6].The higher the utility score is, the more interested the user is to the event.Besides, the spatial distance is another import factor in personalized planning; the total travel cost of a plan should not be more than the travel budget of the user.Moreover, a user may participate in more than one events; the platform should guarantee that the time periods of events that the user participate in are not overlapped.Therefore, the goal is to make plans for all the users to maximize the utility score where the travel cost of each user cannot be more than his budget and events in the same plan do not conflict with each other.
Example .Suppose we have 5 users and 3 events, and details are shown in Table 1.The first row describes users and their travel budget, and the first column gives the events and the upper user bound.The last column is the time period when each event is held, and the time period of  2 and  3 are overlapped.It means that users cannot participate in both  1 and  3 .The other columns are the utility scores of each user.The locations of users and events are shown in Figure 1.The locations are described in a 2D space and the distance between any two locations is Euclidean distance.For a user, he starts from his current location, participates in each event in his plan one by one, and goes back to his start location.For example, the purple lines are the plan of  2 .He starts from (8,2), participates in  3 and  1 , and go back to (8,2) at last.The travel cost is 16.9, which is no more than the travel budget.The total utility of all users whose plans are shown in Figure 1 is 3.7.(2,9) u 1 (6,5) e 1 (7,8) e 2 (2,5) u 5 (4,2) u 3 (14,8) e 3 (13,5) u 2 (8,2)   (10) 0.9 0.5 0.9 Existing studies [2][3][4][5][6] only focus on the utility of users.However, the event organizers also have preference towards users for holding the event successfully.For example, organizers prefer users who are more influential in the social network to participate in their events, which may improve the quality of the events.Therefore, the personalized planning problem over EBSNs should be a bilateral planning problem among users and events.The existing techniques cannot give plans that satisfy both users and event organizers.For Example 1, we give the utility scores of events to users in Table 2.  1 ,  2 , and  4 are the worst three users of  1 . 2 prefers  4 than  5 . 2 and  3 are not the best users of  3 .Through analysis, these methods cannot consider the preference of both users and events at the same time.
Based on the aforementioned example, it is more reasonable to consider bilateral preference of users and events than to only consider the preference of users in real applications.Moreover, the events may be modified for some reasons; the plans for users should be updated quickly once it happens.Therefore, we formally define a new personalized planning problem in EBSNs.Different from existing studies, this problem is a bilateral planning problem which considers the preference of both users and events instead of only considering the preference of user and the attributes of user and events change dynamically.In summary, to solve this problem, we make the following contributions: (i) We identify a new Incremental Bilateral Preference Stable Planning (IBPSP) problem over EBSNs, which aims to dynamically make plans satisfying both users and event organizers.(ii) We present solutions to give stable plans in different situations as the attributes of users and events change.(iii) We verify the effectiveness and efficiency of the proposed methods with extensive experiments on real dataset.
The rest of this paper is organized as follows.Section 2 briefly introduces some basic concepts and formalizes the problem.In Section 3, we give the solutions for different conditions.Extensive experiments are conducted on a series of real-life datasets and the performance is evaluated in Section 4. Section 5 discusses the related works.Finally, we give our conclusion in Section 6.

Problem Statement
In this section, we introduce some basic concepts of EBSNs firstly.And then, we formally define the Incremental Bilateral Preference Stable Planning (IBPSP) problem.Symbols used in our paper are shown in Table 3.
Given an event based social network with  users and  events, we denote  as the user set and  as the event set.Each user   ∈  is described by a 2-tuple ⟨l   ,   ⟩ , where l   is the location of   in a 2D space, and   is the travel cost budget.Each event   ∈  is described by a 4-tuple ⟨l   ,   ,    ,    ⟩, where l   is the location of   in a 2D space,   is the largest The utility score of   to     (  ,   ) The utility score of   to   (  ) The preference rank of   to all the events (  ) The preference rank of   to all the users P The global plan P(  ) The set of events that   will participate in P(  ) The set of users who will participate in   number of participants, and    and    are the start time and end time of   .For user   , the utility score to event   is denoted as   (  ,   ), and the utility score of   to   is denoted as   (  ,   ), where   (  ,   ),   (  ,   ) ∈ [0, 1].We denote the preference rank of   is (  ), and the preference rank of   is (  ).The order of utility scores is strict; that is, no two utility scores are equal.
A global plan P is a set of plans for all the users in the platform, denoted as P = {(  ,   ) | 1 ≤  ≤ , 1 ≤  ≤ }.Events in each user's plan cannot conflict with each other.In other words, for two events   and  ℎ in the same user's plan, if   starts before  ℎ ,   should end earlier than  ℎ .A user may participate in several events according to his plan; the travel cost is the sum of the distance that he travels.The distance between users and events is Euclidean distance.
Definition (blocking pair).For a user   and an event   , where (  ,   ) ∉ P and the travel budget is enough to participate in   , if   prefers   to at least one event in his plan and   prefers   to at least one user that will participate in   , then (  ,   ) is a blocking pair.
Due to the existing of travel budget, the travel cost may be larger than the budget of   after the platform arrangements   participate in   .In this case, (  ,   ) is not a blocking pair.
Back to Example 1, according to the plans in Figure 1 and the utility scores in Tables 1 and 2, ( 4 ,  2 ) is a blocking pair.The reason is that  4 prefers  2 to  1 , and  2 prefers  4 to  5 .( 5 ,  3 ) is not a blocking pair.The reason is that the travel budget of  5 is not enough to travel to  3 , though they prefer each other.Figure 2 shows planning results without the blocking pairs.After defining the above concepts, we next introduce the IBPSP problem as follows.
Definition (IBPSP problem).Given a set of users , a set of events , the preference rank , and  over an EBSN platform, which allows the attributes of users and events change dynamically, the IBPSP problem is to find a global plan P for all the users such that the following constraints are satisfied: (i) Events in the same user's plan do not conflict with each other, where (iii) The number of participants is not more than the upper bound of events, where (iv) The global plan does not contain any blocking pairs.
(v) The plan is updated when the attributes change.
In the IBPSP problem, both users and events do not prefer other events and users that are out of the plan, it will reach a stable state.From the perspective of economics, in the existence of competitive relations, the stable state is the most reasonable and the most consistent with the law of development of things [7].In practice, information of events and profiles of users are subject to change.Thus, a reasonable event planning system should support incremental updates.

Solutions to IBPSP Problem
In this section, we first introduce which attributes of users and events may change.And then, we propose several solutions to deal with the changes and update the plans that are made based on the former attributes.

. . Changes Caused by Users and Events
Travel Budget of Users.Users can modify their travel budget according to their own intentions.For example, if a user has enough to enjoy the events, he may increase the travel budget to travel further or participate in more events.A user may also travel a shorter distance or even cancel the travel plan due to the bad weather or fall ill.
Participation Upper Bounds of Events.The maximum capacity of the events is limited by a number of factors.For example, if the event is more popular than expected, the organizers may choose a larger venue and increase the upper bound of participations.The opposite, however, is also possible.If a tourism interest group organizes a visit to a scenic spot, the organizer may reduce the number of people due to the restricted traffic conditions of the scenic spot.
Start Times and Times of Events.The organizer may modify the start or end time if the venue is occupied during the time period when the event will be held or some important guests cannot participate in the event on time.
Events Are Added or Cancelled.In EBSNs, new events will be added at any time.When a new event is added, the platform needs to arrange suitable users to participate in this event.The planned events can also be cancelled for all kinds of reasons.When it happens, the platform needs to arrange users to participate in other events that are suitable for them.
. .Solutions.In this section, suppose the platform has made plans for users.And then, the changes which are introduced above come.We provide solutions on how to solve the changes when the changes happen.
. . .  Is Decreased.When the travel budget of a user decreases, it may lead to that he cannot participate in some events that are planned by the platform for him.The platform needs to remove some events from his plan until the total travel cost is no more than the budget.What is more, the plans also need to be adjusted to make sure that there are no blocking pairs in the new plan.
The pseudocode is illustrated in Algorithm 1.When the travel budget of   changes, we first initialize a set   as an empty set (Line 2).  stores the events that are affected by the change.While the travel cost is larger than the travel budget, we find an event   in P(  ) whose utility score is the lowest in PU(  ), remove it from P(  ), and put it into   (Lines 3-6).After this step, we make sure that the travel cost is not greater than the new travel budget.Since   cannot participate in some events, there may be blocking pairs in the plans of these events.Finally, Algorithm 2 is called to update the plans of events in   .
Algorithm 2 terminates until  ac is empty and returns a new global plan.In each loop, we pop an event   from   (Line 3) and start to enumerate each user   whose utility is not greater than the lowest utility in current plan P(  ) until the number of participants equals   (Lines 4-5).If   conflicts with   that has a higher utility in (  ), then we start again from the next user (Lines 7-9).Otherwise, we remove the events whose utility is less than   from P(  ) and put them in a conflict set and they are also put into   (Lines 10-12).Then we can add   to P(  ) (Line 13 is greater than the travel budget, we remove some events and put them into the conflict set and   (Lines 14-20).If   is also removed in the former step, it means   is too fat for   to participate in, and P(  ) is rehabilitated (Lines 21-25).
Example .Based on the planning of Figure 2, suppose that the travel budget of  1 decreases to 5.Then,  3 is removed from P( 1 ) and put into E  .We pop  3 from E  , and  3 can participate in it; a new stable planning is constructed.
. . .  Is Decreased.When  decreases, the number of participants may exceeds the new upper bound in current plans.The platform needs to remove some participants and adjust the plans of these participants.
The pseudocode is illustrated in Algorithm 3. When   changes, we first initialize a set   as an empty set (Line 2).  stores the users that are affected by the change.While the number of participants is larger than the new upper bound, we find a user   in P(  ) whose utility score is the lowest in PE(  ), remove him from P(  ), and put it into   (Lines 3-6).After this step, we make sure that the new  is satisfied.Finally, Algorithm 4 is called to update the plans of users in   .Algorithm 4 terminates until   is empty and return a new global plan.In each loop, we pop a user   from   (Line 3) and start to enumerate each event   whose utility are not greater than the lowest utility in current plan P(  ) (Lines 4-5).If   conflicts with   that has a higher utility in P(  ), then we start again from the next event (Lines 6-8).Otherwise, add   ,   into P(  ), P(  ) (Line 9).If the number of participants exceeds   , we remove the user with the lowest utility in P(  ) and put the user into   if he is not   (Lines 9-18).Finally the new global plan P is returned (Line 21).
Example .Based on the planning of Figure 2, suppose that the participant bound of  3 decreases to 1.Then,  3 is removed from the planning of  2 , and  2 is put into   .We pop  2 from   , then  2 is removed from the planning of  4 and  4 is put into   . 4 cannot participate in other events; a new stable planning is constructed.

. . . 𝑡 𝑠
or    Is Changed.If the start or end time changes, it may cause many conflicts in the original plan P.There are four kinds of cases that the global plan needs to be updated: (1) the new event conflicts with events that with higher utility scores in users' plans, (2) the event does not conflict with events with higher utility scores in the same plan, however, some events with lower utility scores that conflict with it, (3) the original event conflicts with some events in the users' plan but the conflicts do not exist after the change, and (4) some events out of users' conflict with the original event but the conflicts do not exist after the change.
The pseudocode is illustrated in Algorithm 5. We initialize   and   at first (Line 1).And then, we find all the users whose plans are affected by the change, remove   from their plans, and put them into   (Lines 3-5).The plan of   is cleared and needs to be replanned (Line 6).For users in   and events in   , we call Algorithms 2 and 3 to update their plans (Lines 7-12).
. . .e Other Situations.We discuss how to solve the other situations, based on the above algorithms.
Is Increased.When the travel budget of a user increases, the user can participate in more events.We can update his plan by putting him into   and calling Algorithm 4.However, we need to make a small change to Algorithm 4. We cannot enumerate events starting from whose utility is not greater than the lowest utility in current plan; it will result in blocking pairs.The user may participate in events with higher utility than events in the current plan, because his travel budget may be large enough to travel to the locations of these events.Therefore, we enumerate events starting from whose utility is the largest and add them into the plan if possible.  Is Increased.When  increases, the event can accommodate more participants; we then put it into   and call Algorithm 2 to update the plans.Note that if the number of participants is less than the original upper bound, the plans need not to be update.
. . .Multiple Changes in One Run.We consider a more complex case in which multiple changes come at the same time.As introduced above, all the changes can be solved by two basic algorithms.The main idea is that we find the events and users whose plans need to be updated and conduct Algorithms 2 and 4 to update their plans.
The pseudocode is illustrated in Algorithm 6.We initialize   and   at first (Line 1).While the travel cost is larger than the travel budget, we find an event   in P(  ) whose utility score is the lowest in PU(  ), remove it from P(  ), and put it into   (Lines 3-6).And then, we find all the users whose plans are affected by the change, remove   from their plans, and put them into   (Lines 7-9).The plan of   is cleared and needs to be replanned (Line 10).For users in   and events in   , we call Algorithms 2 and 3 to update their plans (Lines 11-17).

Performance Evaluation
In this section, we provide an empirical evaluation of our proposed algorithms, including the experimental environment, algorithm running time, memory cost, and the total sum of utility scores of users.
. .Experiment Environment and Dataset.We conduct our algorithms over a real-life dataset, the Meetup dataset [1], which is a popular event based social network.The dataset records the locations of users and the tags that indicate the interesting points of the users.It also records the locations of events where they are held.The events are held by interesting groups; therefore, the tags of events are the tags of whom hold them.The utility scores are calculated as the method in [1].We extract six datasets of different cities according to the longitude and latitude and generate other parameters, summarized in Table 4.We also use a synthetic dataset to test the scalability of our algorithms, shown in Table 5.
The algorithms are implemented in Visual C++ 2017, and the experiments are conducted in a Windows 10 machine with Intel(R) Core(TM) i5-6500 3.20GHz CPU and 16GB main memory.When the changes come, we treat all the events as new added and get a global plan as the contrast experiment, named Re-Plan.In each experiment, we repeat 10 times and report the average results.
. .Results on Real Dataset.In this section, we test the performance of our algorithms, denoted as -De, -De,   −   , and , on Meetup datasets.For each algorithm, we randomly select several users to decrease their travel budget and several events to decrease their upper bound of participations one by one.For the multiple case, we randomly select some users and events of the three kinds of changes.
The experiment results are shown in Tables 6-9.The utility scores of -De are the same as Re-Plan.The reason is that -De conducts the same algorithm to update the plans of events as Re-Plan.In other cases, the algorithms are similar with Re-Plan.-De is better than Re-Plan on Hawaii and Vancouver,   −   is better on Hawaii and Hong Kong, and  is better on Singapore and Vancouver.In IBPSP problem, the stable plan is not unique; we can find different stable plans through different algorithms.Though the utility scores are not the same, the plans are still stable.In all the algorithms, the running time is much smaller than the Re-Plan; the reason is that the incremental algorithms only adjust the plans of users and events that are affected by the changes, but the Re-Plan makes plans for all the users and events over again.The running time increases as the data size increases.The incremental algorithms cost the similar memory as Re-Plan due to the fact that they all need memory to store the preference and the final plans.Mul costs a bit more memory than others due to size of   and   is larger than others.
. .Results on Synthetic Datasets.In this section, we test the scalability of the proposed algorithms on synthetic datasets.We first set || as 5000 and change || from 200 to 5000.Then, we set || as 1000 and change || from 200 to 5000.
The results of efficiency are shown in Figure 3.The total utility increases as the data size increases.The total utility of -De is still as same as Re-Plan as shown in Figures 3(a The results of effectiveness are show in Figure 4.Both the running time and memory cost increase as || and || increase.  −   and  cost more time than the others, the reason is that the plans adjusted in the two algorithms are more than the others.-De runs faster than -De when || increases but runs the slowest when || increases.The reason is that -De needs to enumerate users while adjusting plans of events; the increasing of || affects the running time.To the contrary, -De needs to enumerate events while adjusting plans of users; the running time increases faster as || increases.

Related Work
In this section, we review related works from two categories, event based social networks (EBSNs) and stable matching problem.
Studies on EBSNs.By analyzing Meetup and Plancust, X. Liu et al. [1] firstly proposed the concept of EBSN and received more and more attention [8][9][10][11][12][13][14][15][16][17].On the event recommendation problem, Zhang et al. [9] predicted whether a user will participate in some events by learning the historical events that the user participated in.Cao et al. [18] scored users based on location information, attributes, and relations and built a Bayesian model to recommend events.Wang et al. [19] proposed a context-enhanced method to recommend events to users.However, the method relies too much on social information and geographical information; the lack and inaccuracy of data will seriously affect the accuracy.On the event organization problem, Shen et al. [3,4] considered the conflict between events and made arrangements for users that avoid conflicts.Authors of [6] took into account the users' travel budget and extended the problem from simply matching the users with events to scheduling reasonable travels for users to participate in events.Cheng et al. [2] further considered the lower bound of the number of participants in the events and the issue of dynamic planning.The existing works only considered the preference of users, none of them studied on the bilateral preference stable planning problem.The authors of [20]    that the man and the woman prefer each other than his/her partner.Reference [22] proved that the stable marriage always exists.There are some extensions of stable marriage problem, SM with incomplete preference lists, SM with preference lists with ties, and SM with incomplete preference lists with ties.In SM with incomplete preference lists, each person's preference list may be incomplete.Authors of [23] partitioned the set of men (women) into two sets: one is the set of men (women) who have partners in all stable matching, and the other is the set of men (women) who are single in all stable matching.In SM with preference lists with ties, one can include two or more persons with the same preference in a tie.Authors of [24] found a weakly stable matching in polynomial time.The last extension allows both incompleteness and ties in preference list.There series of approximation algorithm [25][26][27][28] and the approximation ratio reached 1.8 in [28].The definition of stable matching problem is different from ours and the attributes are not changed dynamically; the existing studies cannot be applied.

Conclusions
In this paper, we define the Incremental Bilateral Preference Stable Planning (IBPSP) problem, which dynamically make plans for all the users to participate in suitable events.In this problem, we consider the upper bound of participants, event time conflicts, and the travel budget of users and dynamically update the plans when the constraints change.We propose several algorithms to update the plans when the changes come.We verify the effectiveness, efficiency, and scalability of the proposed methods through extensive experiments on both read and synthetic datasets.

Figure 1 :
Figure 1: The location of users and events.

Figure 2 :
Figure 2: A planning without blocking pairs.
) and 3(b).-De is better than Re-Plan as || increases.  −   and Mul are better than Re-Plan as || and || increase.
Memory cost versus ||

Table 1 :
Users' utility to each event.

Table 2 :
Events' utility to each user.

Table 3 :
Summary of symbols used in our paper.The end time of    The travel cost of     (  ,   ) ← 0 While(D  >   )   ← event with the worst utility score in P(  ) Put   into   , remove   ,   from P(  ), P(  ) EndWhile ReturnUpdate event plan(, , , , P  ,   ) Algorithm 1: Budget decreasing algorithm.
The travel cost of users is not more than their travel budget, where ∀    ≤   .Input: , , , , P  ,   Output: P P ← P , , , , P  ,   Pop   from    ℎ ← user with the worst utility in P(  ) F o r e a c h(  after  ℎ in (  ) ⋀ the number of participants does not exceed   )  V =  I f (∃  ∈ P(  ) that conflicts with   )  ∈ P(  )) Remove   from P(  ), put   into  V, put   into   EndFor Put   into P(  ) While(  >   ) Remove the worst event   from P(  ) If(  is removed) break EndIf Put   into  V, put   into   EndWhile If(  has been removed from P(  )) Foreach(  ∈  V) Put   back to P(  ), remove   from ).If the travel cost Input: , , , , P  ,   Output: P P ← P    ← 0 While(|P(  )| >   )   ← user with the worst utility score in P(  ) Put   into   , remove   ,   from P(  ), P(  ) Endwhile ReturnUpdate user plan(, , , , P  ,   ) Algorithm 3:  decreasing algorithm.Pop   from Input:  ← event with the worst utility in P(  ) F o r e a c h(  after   in (  )) I f (∃ ℎ ∈ P(  ) conflicts with   ) b r e a k E n d I f Add   ,   into P(  ), P(  ) If(the number of participants exceeds   ) If(  is the worst user in P(  )) Remove   ,   from P(  ), P(  ) break; ElseIf Remove the worst user   from P(  ) Put   into , , , , P  ,   Output: P   = ,   = 0 P ← P  Foreach(  ∈ P(  )) Remove   from P(  ), put   into   EndFor Empty P(  ), put   into   Remove   from P(  ), put   into   EndFor Empty P(  ), put   into Input: Input: , , , , P  ,   ,   Output: P   = ,   = 0 P ← P  While(D  >   )   ← event with the worst utility score in P(  ) Put   into   , remove   ,   from P(  ), P(  ) Endwhile Foreach(  ∈ P(  ))

Table 6 :
Results of -De on real datasets.

Table 7 :
Results of -De on real datasets.

Table 8 :
Results of   −   on real datasets.

Table 9 :
Results of  on real datasets.