Abstract
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 selecting interesting events for users. However, for organizers of events, they also would like more high-quality users to participate in their events, which may make the events more exciting. Existing studies are user-centered and ignore the requirement of organizers. What is more, organizers are allowed to modify their events dynamically before they are held. The platforms should be able to dynamically adjust the schedules of users. Therefore, we identify a new Incremental Bilateral Preference Stable Planning (IBPSP) problem over EBSNs and propose several solutions to deal with different situations. We conduct extensive experiments to verify the efficiency and effectiveness of the proposed algorithms.
1. 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–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 1. 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 and are overlapped. It means that users cannot participate in both and . 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 . He starts from , participates in and , and go back to 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.
Existing studies [2–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. , , and are the worst three users of . prefers than . and are not the best users of . 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.
2. 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 , where is the location of in a 2D space, and is the travel cost budget. Each event is described by a 4-tuple , where is the location of in a 2D space, is the largest 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 , . 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 is a set of plans for all the users in the platform, denoted as . 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 2 (blocking pair). For a user and an event , where 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, is a blocking pair. The reason is that prefers to , and prefers to . is not a blocking pair. The reason is that the travel budget of is not enough to travel to , 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 3 (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 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 .(ii)The travel cost of users is not more than their travel budget, 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.
3. 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.
3.1. 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.
3.2. 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.
3.2.1. 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 whose utility score is the lowest in , remove it from , 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 .
| Input: , , , , , | |
| Output: | |
| 1 | |
| 2 | |
| 3While() | |
| 4 event with the worst utility score in | |
| 5Put into , remove , from , | |
| 6EndWhile | |
| 7Return Update_event_plan(, , , , , ) |
| Input: , , , , , | |
| Output: | |
| 1 | |
| 2While() | |
| 3Pop from | |
| 4 user with the worst utility in | |
| 5Foreach ( after in the number of participants does not exceed ) | |
| 6 | |
| 7If( that conflicts with ) | |
| 8continue | |
| 9EndIf | |
| 10Foreach() | |
| 11Remove from , put into , put into | |
| 12EndFor | |
| 13Put into | |
| 14While() | |
| 15Remove the worst event from | |
| 16If( is removed) | |
| 17break | |
| 18EndIf | |
| 19Put into , put into | |
| 20EndWhile | |
| 21If( has been removed from ) | |
| 22Foreach() | |
| 23Put back to , remove from | |
| 24EndFor | |
| 25EndIf | |
| 26EndFor | |
| 27Endwhile | |
| 28Return |
Algorithm 2 terminates until 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 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 and put them in a conflict set and they are also put into (Lines 10-12). Then we can add to (Line 13). If the travel cost 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 is rehabilitated (Lines 21-25).
Example 4. Based on the planning of Figure 2, suppose that the travel budget of decreases to 5. Then, is removed from and put into . We pop from , and can participate in it; a new stable planning is constructed.
3.2.2. 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 whose utility score is the lowest in , remove him from , 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 .
| Input: , , , , , | |
| Output: | |
| 1 | |
| 2 | |
| 3While() | |
| 4 user with the worst utility score in | |
| 5Put into , remove , from , | |
| 6Endwhile | |
| 7Return Update_user_plan(, , , , , ) |
| Input: , , , , , | |
| Output: | |
| 1 | |
| 2While() | |
| 3Pop from | |
| 4 event with the worst utility in | |
| 5Foreach ( after in ) | |
| 6If( conflicts with ) | |
| 7break | |
| 8EndIf | |
| 9Add , into , | |
| 10If(the number of participants exceeds ) | |
| 11If( is the worst user in ) | |
| 12Remove , from , | |
| 13break; | |
| 14ElseIf | |
| 15Remove the worst user from | |
| 16Put into | |
| 17EndIf | |
| 18EndIf | |
| 19EndFor | |
| 20Endwhile | |
| 21Return |
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 (Lines 4-5). If conflicts with that has a higher utility in , then we start again from the next event (Lines 6-8). Otherwise, add , into , (Line 9). If the number of participants exceeds , we remove the user with the lowest utility in and put the user into if he is not (Lines 9-18).Finally the new global plan is returned (Line 21).
Example 5. Based on the planning of Figure 2, suppose that the participant bound of decreases to 1. Then, is removed from the planning of , and is put into . We pop from , then is removed from the planning of and is put into . cannot participate in other events; a new stable planning is constructed.
3.2.3. or Is Changed
If the start or end time changes, it may cause many conflicts in the original plan . 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).
| Input: , , , , , | |
| Output: | |
| 1 | |
| 2 | |
| 3Foreach() | |
| 4Remove from , put into | |
| 5EndFor | |
| 6Empty , put into | |
| 7If() | |
| 8Update start users(, , , , , ) | |
| 9EndIf | |
| 10If() | |
| 11Update start events(, , , , , ) | |
| 12EndIf | |
| 13Return |
3.2.4. The 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.
3.2.5. 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 whose utility score is the lowest in , remove it from , 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).
| Input: , , , , , , | |
| Output: | |
| 1 | |
| 2 | |
| 3While() | |
| 4 event with the worst utility score in | |
| 5Put into , remove , from , | |
| 6Endwhile | |
| 7Foreach() | |
| 8Remove from , put into | |
| 9EndFor | |
| 10Empty , put into | |
| 11If() | |
| 12Update start users(, , , , , ) | |
| 13EndIf | |
| 14If() | |
| 15Update start events(, , , , , ) | |
| 16EndIf | |
| 17Return |
4. 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.
4.1. 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.
4.2. 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. costs a bit more memory than others due to size of and is larger than others.
4.3. 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) and 3(b). -De is better than Re-Plan as increases. and are better than Re-Plan as and increase.
(a) Total utility versus
(b) Total utility versus
(c) Total utility versus
(d) Total utility versus
(e) Total utility versus
(f) Total utility versus
(g) Total utility versus
(h) Total utility versus
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.
(a) Running time versus
(b) Running time versus
(c) Memory cost versus
(d) Memory cost versus
5. 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–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] studied a kind of stable matching problem over EBSNs; however, our work studies an incremental problem which is different from it.
Studies on Stable Matching Problem. The stable marriage (SM) problem was first proposed by Gale and Shapley [21] in 1962. Suppose a set of man and a set of woman with the same size; a stable marriage for these men and women is that everyone is matched with a partner and there are no such two couples 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–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.
6. 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.
Data Availability
The Meetup data supporting the finding of this study are from previously reported studies and datasets, which have been cited as [1]. The processed data are available from the corresponding author upon request.
Conflicts of Interest
The authors declared that they have no conflicts of interest to this work
Acknowledgments
The work is supported by the National Key R&D Program of China (Grant no. 2016YFC1401900), the National Natural Science Foundation of China (Grants nos. 61332006, 61332014, 61328202, U1401256, 61572119, 61622202, 61572121, and 61702086), the Fundamental Research Funds for the Central Universities (Grants nos. N150402005, N171604007, and N171904007), the Natural Science Foundation of Liaoning Province (Grant no. 20170520164), and the China Postdoctoral Science Foundation (Grant no. 2018M631806).