Ambiguity Handling in Mobile-capable Social Networks

Transcription

1 Ambiguity Handling in Mobile-capable Social Networks Péter Ekler Department of Automation and Applied Informatics Budapest University of Technology and Economics Abstract. Today we experience the proliferation of social networking applications. However mobile devices are only scarcely involved as individual members in such networks. In this paper we investigate how mobile phones can participate in social networks. The phonebook of the mobile devices represents basically a small social network which belongs to the owner of the device. The paper introduces mobile-capable social networks which enables users to synchronize their phonebooks to the social network. However this solution raises problems that are not experienced by general-purpose social networks. It is possible that after the synchronization there will be duplicated profiles in the network. In the paper we discuss this ambiguity handling problem and introduce our algorithm for detecting and resolving similarities. Keywords: Social network; Mobile device; Phonebook; Ambiguity handling 1 Introduction Social networks are becoming more and more popular. A social network is a social structure consisting of nodes, which generally correspond to individuals or organizations. Nodes are connected by one or more specific types of dependency. A few years ago nobody expected that social networks would be so popular, and it may seem surprising that very often even older people use social networking applications for different reasons. Social networks have an important role to play in everyday life; we use them to find other people, send messages to each other, manage our personal site, share photos and videos, etc. From another point of view, a social network is an environment that is created by the people who are using it. There are various kinds of social networks with different functionality but the general principles are the same. The most popular social networks include Myspace, Facebook, iwiw (in Hungary). These systems have several millions of users and it is also quite common that users have accounts for different social networks; this way these are somehow interconnected by their users as well. Another common characteristic of these systems is that they have a web-based interface and users can reach them from any web browser. Mobile phones and mobile applications are another hot topic nowadays. More and more people are using different types of mobile devices. Both hard- 1

2 ware and software capabilities of mobile phones have been evolving in the last decades. Most of the devices are able to create images and videos, play music and other multimedia content. In addition, we can even run complex software on them. As the functionality of mobile phones is expanding, people spend more time using their devices. There are several approaches to using mobile phones in social networks but these are mainly limited to adding extra functionality to support mobile devices. These typically include photo and video upload capabilities and enabling mobile phones to reach web-based social networking functionality from the mobile side. However, if we consider the contact list in our mobile device, we realize that basically it is a small social network because every contact in our phonebook has some kind of relationship to us. Given an implementation that allows us to upload as well as download our contacts to and from the social networking application, we can completely keep our contacts synchronized so that we can also see all our contacts on the mobile phone as well as on the web interface. However this approach raises problems that are not experienced by generalpurpose social networks. Consider the case that we have a contact called John Doe in our phonebook and we have him also in the existing social networking application. Let us suppose we synchronize our contacts. How does the system realize that these contacts are the same? What happens if we have two or more matching contacts in the system? How should the system react to this kind of similarity? In the discussion that follows, we will reference to this problem as ambiguity handling. To answer these questions, we use an experimental implementation of a social networking application which supports mobile phones in the aforementioned manner. This application is not currently open to the public but still it has about three hundred users who have altogether more than twenty thousand contacts in their mobile phones and they use this system to keep their social relationships synchronized. Social networks that handle mobile devices have several interesting research implications. For instance, they can offer not only searching according to usual social network query criteria (e.g. name or workplace) but also location-based functionality such as automatic recommendation of a contact person who is close to us. In this paper, we investigate the previously described ambiguity handling and we show a method which can be used to detect and handle ambiguities in a comfortable way from the point of view of usability. The rest of paper is organized as follows. Section 2 describes related work in the area of social networks and mobile-based solutions. Section 3 gives dentitions and problem context, which is necessary to understand the proposed ambiguity handling solution. Section 4 introduces our algorithm for detecting and handling similarities. Section 5 concludes the paper and proposes future research directions. 2

3 2 Related work Nowadays, the number of social network users is increasing, thus the efficient implementation of these networks is an important research area. Newman et al. [1] describe some novel uniquely solvable models of the structure of social networks based on random graphs with arbitrary degree distributions. They give models both for simple unipartite networks such as acquaintance networks and bipartite networks such as affiliation networks. They compare the predictions of their models to data from a number of real-world social networks and find that in some cases, the models are in remarkable agreement with the data, whereas in others the agreement is not so good, perhaps indicating the presence of additional social structure in the network that is not captured by the random graph. There are several existing international web-based social networking solutions that people use every day. MySpace [2] is one of the most popular social networking websites offering an interactive, user-submitted network of friends, personal profiles, blogs, groups, photos, music and videos for teenagers and adults internationally. Facebook [3] is a social utility that connects people with friends and others who work, study and live around them. People use Facebook to keep up with friends, upload an unlimited number of photos, share links and videos and learn more about the people they meet. Bakos et al. [4] have investigated that search engines generally lack the trust and personalization dimension needed for recommendation systems to answer questions like: I need a reliable plumber close to my house. In order to achieve personalization, social relevance and a decent amount of privacy, the search database itself needs to be personalized. One possible dimension of personalization is the social neighborhood of the searcher. In particular, the phonebook links represent a readily available infrastructure to create a peer-to-peer social network for socially relevant search. They have demonstrated their concept via a novel search engine algorithm for phonebook entry-based social networks on S60 mobile platform over GSM using short message exchange. Searching for a good professional in a given area can be as simple as entering an appropriate combination of keywords in Google [5] or Yahoo [6] e.g. plumber New York. The results will be more or less reliable and related to the plumber profession in the area of New York. Both Google and Yahoo offer an additional yellow pages service that makes the search easier. However, if we now turn to other jobs or hobbies like fisher, there will be a huge difference. It turns out that there are a large number of persons called Fisher. The system does not differentiate very well between names and professions: the introduction of the word fisher in the yellow pages will result in many Fishers, having various professions. We investigated in a previous paper [7] how mobile devices can connect to a web-based social network. In that paper we outlined an architecture where mobile devices were able to connect to a social network via web services. We have also demonstrated this solution with a web-based social network whose 3

4 functions were available via web services and a mobile client which was able to reach all of the functions of the social network. The key difference between our current work and previous research is that these social networking solutions do not allow mobile phones to become an integrated member of the social network. They do not fully utilize that the phonebook in these devices is in itself nothing else but a small yet very important social network. 3 Definitions and problem statements Before we introduce our ambiguity handling solution we have to clarify some definitions and terms. The first definition describes what we exactly mean by a social network which handles mobile devices Figure 1. Definition 1. Mobile-capable social networks are special social networks which are extended with the phonebook entries of each user who has a mobile device. It is able to keep the acquaintances and the phonebook contacts of the users synchronized. Figure 1: Mobile-capable social network In a general social network, the users are basically the persons who are registered in the system. Most commonly, users are able to set their profile after their registration including phone numbers, addresses, hobbies, job titles, topic of interests, etc. In our case, we had a simplification we could turn to our advantage. We decided to store the same information in the social network about persons as present in the phonebook of the mobile device. This is not a real limitation as a general phonebook entry can already store several pieces of information about a contact such as first name, last name, nickname, job title, company, birthday, address, phone number, and web address. An important aspect is the case of multiple entries: we can store multiple addresses, phone numbers, s and web addresses of a person just as in the mobile device phonebook. From the previous definition it follows that this type of social network has to handle two different types of users: general members and private contacts. Next, we define these two types of users. 4

5 Definition 2. A member is a user who has registered to the system on its website. Basically, members are similar to users of other general social networks. They can log into the system, find and add acquaintances, upload and share information about themselves, write forum or blog entries, etc. Furthermore, they can synchronize their mobile phones to the social network. Definition 3. A private contact is transferred into the system when a member synchronizes his or her phonebook with the social network. Essentially, a private contact corresponds to a phonebook entry of a member. Each member may have multiple private contacts. However, these private contacts are not shared between members. With the help of these definitions we can clarify what we exactly mean by ambiguity handling. When a member synchronizes his or her phonebook, the contacts of the phonebook will be added to the social network. Ambiguity means that a private contact represents the same person as one of the acquaintances of the member. In this case, a member would have a duplicated entry for the same person, one for the member and the other for the private contact Figure 2. Figure 2: Handling ambiguity during synchronization There are several solutions not related to social networks that try to detect and handle duplicated contacts but they have several limitations and constraints. One of these is when users synchronize their contacts between the popular Outlook application and their Nokia phones via the Nokia PC-Suite application. However, this solution detects ambiguities only if persons have the same first and last name. Otherwise, the synchronization results in duplicating the contact. For example, if two contacts in the data sources represent the same person (e.g. they have the same phone number and address) but on the phonebook the last name field was not filled, the contact will be copied from one source to the other and vice versa. Another application called DupeDeDupe [8] for Windows Mobile-based devices searches for duplicate contacts from the address book and removes one of the duplicated results. DupeDeDupe compares fields as well as home, work, and mobile phone numbers of each contact. If all of those fields match, the application considers the contact to be a duplicate. 5

6 These solutions are based on exact field matching and therefore often lead to false matches: for example, they detect several persons to be identical based on the phone number even if these phone numbers represent a central work phone number. Another issue is that they do not detect similar names like Joe and Joseph. The last definition in this section describes a vector which can be used to measure how a person is similar to a social network. Definition 4. The similarity vector belongs to the contact entry of a person and the dimension of the vector depends on how many attributes of the contact is filled. The values of the vector represent that how many similarities were found in the social networks related to that attribute. For instance if the following contact structure represent a person: (first name: John; last name: Doe; phone number: ) and the similarity vector to this person is (10,2,0) then it means that there are ten persons in the social network with the first name of John and two with the last name of Doe and there are nobody who has the phone number of In the next section we will use this definition to determine the upper bound of how many similarities can an ambiguity detecting algorithm found and we will prove that our algorithm is bellow this value. 4 Ambiguity detecting and handling 4.1 Algorithm description Most of the contact similarity detecting algorithms are based on comparing somehow the attributes of the contacts. As we have mentioned earlier in a mobile-capable social network we had the advantage that we could determine what kind of attributes we store in a profile. Based on these attributes we can define which attribute match terms do we consider as relevant for the similarity detecting. We have also defined a weight value to each of the terms which represents how relevant is that match. Table 1 introduces match terms and their weights. Table 1: Relevant match terms Match term Weight Similar first and last name 30 Similar private phone number 10 Similar public phone number and first name 10 Similar address 15 Different birthday -40 6

7 In Table 1 the private phone number means mobile phone number, home phone number, pager number, etc., while public phone number means fax number, workplace number, etc. During the synchronization, when the algorithm has to decide whether the new private contact is similar to a member, it calculates a similarity-weight value. It checks the previously introduced match terms and if one of the match terms turns out to be true then the weight value of it will be added to the similarity-weight value. This way after the algorithm compared a private contact and a member, the result will be the calculated similarity-weight value and if it is more than a specific value (currently in our case it is 10) then this case will be considered as possible similarity. Algorithm 1 describes how we can check the private contacts and acquaintances of the user who is doing the synchronization. The main similaritycheck function will call checkmatchterm function several times to check a specific match term. Algorithm 1 Ambiguity detecting for a user 1: function checkmatchterm(matchterm, matchtermweight, 2: PC, &possiblesimilarmembers) 3: tempsimilarmembers = array() 4: 5: for all acquaintances (AC) of the user do 6: if matchterm(pc,ac) then 7: addtoarray(tempsimilarmembers,struct(ac,matchtermweight)) 8: 9: if size(tempsimilarmembers)<maxmatchlimit then 10: // merge the arrays, and if a member is already in the possiblesimilarmembers 11: // array then also calculate the new weight to it 12: mergearrays(similarmembers,tempsimilarmembers) 13: 14: 15: function similaritycheck(user) 16: for all private contact (PC) of the user do 17: possiblesimilarmembers = array() 18: 19: checkmatchterm(matchnames,30,pc,possiblesimilarmembers) 20: checkmatchterm(matchprivatephones,10,pc,possiblesimilarmembers) 21: checkmatchterm(matchprivatephones,10,pc,possiblesimilarmembers) 22: checkmatchterm(match s,-40,pc,possiblesimilarmembers) 23: 24: for all possiblesimilarmembers (SM) do 25: if SM.weight>minSimilarityWeight then 26: storesimilarity(pc,sm.member,sm.weight) 7

8 We can see on Table 1 that the "Different birthday" term has a negative value. It means that if two persons have different birthdays then the algorithm decreases the similarity-weight value because it is a relevant difference. Another interesting part of our algorithm in function checkmatchterm states that if a match term check results too many possible similar members then the algorithm ignores this term for this private contact because it means that it is not relevant. It can happen if the phone number of a private contact is central phone number of a company and many other people have entered this phone number in their profiles. These weight values are based on measurements in an experimental implementation of a mobile-capable social network which was mentioned in the Introduction section, however with these values the rate of the detected false similarities is bellow ten percent. The weight values of the current algorithm are fixed however we are planning to implement a learning algorithm which will calculate this weight values based on the decisions of the users whether they have resolved or ignored a detected similarity. 4.2 Handling similar names The algorithm is able to detect similar names like Joe and Joseph which improve the probability to detect similarities even if people have entered names different way. We have implemented the similar name handling by using a similarnames table Table 2. When people use the system and resolve similarities then at each resolve the system checks whether the currently resolved persons have the same first name. If not then the system stores in the similarnames table that these first names are similar because they were resolved by the users manually. Table 2: Similar names name1 name2 count Joe Joseph 10 Katharine Kate 7 Samantha Sam 2 The system also counts how many times these similar but different first names were resolved and if it reaches a specific number then the ambiguity detecting algorithm will use this first name similarity in the first name match term. 4.3 Resolving similarities When we speak about ambiguity handling, we have to realize that there is no perfect algorithm to detect and handle these kinds of similarities. There is a chance that a contact is falsely identified as a duplicate (which is unavoidable for a common name like John Smith) and it would be a serious mistake to delete 8

9 the contact in this case. This example proves that the ambiguity handling algorithm needs a step where users can resolve the ambiguity interactively. In this disambiguation step the user has to decide whether this similarity is a real similarity or a false one. Figure 3 introduces the resolve similarity form in our implementation. Figure 3: Resolve similarity 4.4 Multiple similarities Another issue is when the ambiguity detecting algorithm finds two or more members similar to a private contact during the synchronization process. This situation occurs more frequently than we would think because people usually enter minimal information about a private contact into the phonebook. Phonebook entries are restricted mainly to a name and a phone number and users do not even define whether the phone number is a private, work or home phone number. To handle multiple similarities (Figure 4) we have to involve users as well to decide which of the detected similar persons is the real one. Figure 4: Multiple similarities 9

10 In order to allow users to handle multiple similarities in an efficient way, we can use the previously introduced similarity-weight value. While the upper bound of this value is not determined because people can have unlimited phone numbers, addresses, etc.; we have to calculate a possibility percent from this value. The possibility percent represents how a person is similar to another one. For example if two persons have the same name then the percent should be large enough but if persons have several similar attributes then the percent should not increase as a straight line. In our current experimental implementation we have used the arcos tangent function because of its characteristic to calculate the possibility percent: percent(weight) = { 50 + weight ( ) 80 + arctan weight π if weight 50 otherwise The possibility percent can be used to order the possible similarities and the most possibly similar person will be the first in the list. By using this possibility percent value we can show the list of possible similar persons easily on the user interface of the website (Figure 5). Figure 5: Multiple similarities on the user interface 4.5 Efficiency of the algorithm It is hard to determine the exact efficiency of an ambiguity detecting algorithm because the behavior of the users is not deterministic. For instance they often leave important attributes empty in profiles and phonebook entries and it is not also rare that they enter attributes to wrong fields. The efficiency of ambiguity detecting algorithms can be measured by how many similarities they detect. We can use the definition of the similarity vector to estimate an upper bound for the detected similarities. The simplest ambiguity detecting algorithm compares the attributes of the person one by one and if one of the attributes matches then it marks the persons similar. We can see that the sum of the elements of the similarity vector represents exactly this upper 10

11 bound. The following lemma summarizes that our algorithm is below the upper bound. Lemma 5. The size of the provided result set of the introduced ambiguity detecting algorithm is bellow the sum of the elements of the similarity vector. Proof. During the algorithm we examine five match term. The first one checks the first and the last names together this way if value a belongs to the first name and value b belongs to the last name in the similarity vector then it can result maximum the value of min(a, b). The second match term checks private phone numbers which can result maximum c values. The third term checks public phone number and first name together. If the similarity vector contains d at value public phone number then this term results maximum the value of min(a, d). The forth term checks addresses which can result maximum e values. The last term checks whether the birthdays are different and because it can only decrease the result of possible matches then we do not have to count with it in this proof. If we add this values we can see that min(a, b) + c + min(a, d) + e < a + b + c + d + e. The value of this lemma is that we could measure the efficiency of our ambiguity detecting algorithm. 5 Conclusions and Future Work In this paper we have introduced a new type of social network which we called mobile-capable social network. Mobile-capable social networks are extended with the phonebook entries of each user who has a mobile device. The network is also able to keep the acquaintances and the phonebook contacts of the users synchronized. To emphasize the advantages of mobile-capable social networks let us assume that if somebody changes his or her phone number in the system and others synchronize their mobile phones to the social network, then their phonebook will be automatically updated with this updated phone number. We have also implemented an experimental version of a mobile-capable social network which has three hundred users with more than twenty thousand private contact. This way we could analyze the problems and interesting research areas which are related to mobile-capable social networks. Mobile-capable social networks raise several interesting issues. In this paper we have focused on the ambiguity handling and resolving. This means that the system has to detect how to handle the situation if a person is duplicated in the social network. We have introduced our algorithm and other connected areas like ambiguity resolving, multiple similarities and handling similar names. With the help of the definition of the similarity vector we have calculated the upper bound value which can be the result of a very simple ambiguity detecting 11

12 algorithm and we have proved that the result of our algorithm is bellow this number. Also our current measurements in our mobile-capable social network shows that the rate of the detected false similarities is bellow ten percent by using the introduced algorithm. Future work will be to improve the current algorithm with learning models, which can control the weight values of the match terms. Currently the implementation logs the decision of the users if they ignore or resolve an ambiguity. While our current implementation is closed for public and has only internal users from the Nokia Siemens Networks, we can also use the log files and behaviors of the users to improve the algorithm. We are also planning to develop the similarity vector definition further because it currently represents only basic field matches and it does not count social network related attributes like similar names, and it also does not make difference between attributes if they are not filled or if they are different. Additional future work will be to examine mobile-capable social networks further and give efficient algorithms for search and recommendation functions. Acknowledgments The authors would like to express their thanks to Zoltán Ivánfi, Tihamér Levendovszky and Hassan Charaf for their support as a scientific advisor. This work has been supported by the Nokia Siemens Networks. References [1] M. E. J. Newman, D. J. Watts, and S. H. Strogatz, Random graph models of social networks, in Proceedings of the National Academy of Sciences, [2] Myspace social networking application. May [3] Facebook social networking application. May [4] B. Bakos, L. Farkas, and J. K. Nurminen, Phonebook search engine for mobile p2p social networks, in Databases and Applications, pp , [5] Google phonebook. May [6] Yahoo! people search. May [7] P. Ekler and H. Charaf, Investigating the role of mobile devices in social networks, in Microcad International Conference, Marc [8] Duplicate contact remover application. delete-duplicate-contacts-with-dupededupe, May