Applications and services that take advantage of social data usually infer social relationships using information produced only within their own context. We propose to combine social information from multiple sources into a directed and weighted social multigraph in order to enable novel socially- aware applications and services. We present GeoS, our early prototype of a geo-social data management service which implements a representative set of social inferences. We demonstrate GeoS’ potential for social applications on a collection of social data that combines collocation information and Facebook friendship declarations from 100 students. On managing social data for enabling socially-aware applications and services. Paul Anderson, Nicolas Kourtellis, Joshua Finnis, and Adriana Iamnitchi. In Proceedings of the 3rd Workshop on Social Network Systems (SNS'10), Paris, France, Apr 2010

1. Distributed Systems Group CSE Department 1
On Managing Social Data for
Enabling Socially-Aware
Applications and Services
Paul Anderson, Nicolas Kourtellis,
Joshua Finnis and Adriana Iamnitchi

2. Distributed Systems Group CSE Department2
Outline
 Current Applications
 Limitations
 Problem Statement
 Solution
 Motivating Social Applications
 A Geo-Social Data Management Service
 Early Experiences with Real Social Data
 Decentralized Solution (not in paper)

3. Distributed Systems Group CSE Department3
Current Applications
 Social knowledge used in applications

4. Distributed Systems Group CSE Department4
Limitations
 Social information collected only from one
application domain
 limited knowledge
 high bootstrap costs
 Information from Online Social Networks
can be misleading
 hidden incentives to have many “friends”
 all friends equal

5. Distributed Systems Group CSE Department5
Problem Statement
How can we utilize the wealth of diverse
social information to enable novel classes
of social applications?

6. Distributed Systems Group CSE Department6
Solution
 Collect social information from multiple
sources - social sensors
 Maintain this information in a directed,
weighted, multi-edge social graph
 Offer a set of basic social inference
functions to allow rapid design of new
socially-aware applications and services

7. Distributed Systems Group CSE Department7
Motivating Social Applications
Silence phone when inappropriate

8. Distributed Systems Group CSE Department8
Motivating Social Applications
Create personalized emergency evacuation routes

9. Distributed Systems Group CSE Department9
Motivating Social Applications
Data placement based on social incentives

10. Distributed Systems Group CSE Department10
Outline
 Current Applications
 Limitations
 Problem Statement
 Solution
 Motivating Social Applications
 A Geo-Social Data Management Service
 Early Experiences with Real Social Data
 Decentralized Solution (not in paper)

11. Distributed Systems Group CSE Department11
GeoS Overview

12. Distributed Systems Group CSE Department12
Social Sensors
 Location (via GPS, GSM)
 Collocation (via BT)
 Schedule (e.g., Google calendar)
 Mobile phone activity (calls, sms)
 Online Social Network interactions
 Emails
 Personal relations (family)
 and others

13. Distributed Systems Group CSE Department13
Research Questions
 GeoS maintains a directed, weighted,
labeled, multi-edge social graph that
stores social information from multiple
social sensors
 Open research issues
 Tags of activities
 Weights for social sensors
 Aging of weights on edges in GeoS

14. Distributed Systems Group CSE Department14
Geo-Social Inference Functions
 Currently GeoS provides 5 basic social
inference functions
 More complex functions can be composed
from those provided
1. friend_test (ego, alter, , w)ɑ
2. top_friends (ego, , n)ɑ
3. neighborhood (ego, , w, radius)ɑ
4. proximity (ego, , w, radius, distance)ɑ
5. social_strength (ego, alter)

15. Distributed Systems Group CSE Department15
Social Strength (ego, alter)
 Quantifies the social strength between
ego and alter
 Result normalized to consider overall
user activity
 Search all paths of 2 social hops max

16. Distributed Systems Group CSE Department16
Neighborhood Inference Example

17. Distributed Systems Group CSE Department17
Social Strength Example
The normalized weight
from A to its adjacent
neighbor B (NW{AB}) is
the sum of all the weights
of the edges from A to B
(aggregating over all types
of interactions between A
and B) divided by the
largest of all the sums of
weights going from user A
to one of its neighbors (D)

18. Distributed Systems Group CSE Department18
Social Strength Example (cont)
The path strength from A
to C through B (PS{ABC})
is the lowest of all the NW
on that path, divided by
the length of the path.
The social strength from
user A to user C
(SocS{AC}) is the largest
path strength from A to C.

19. Distributed Systems Group CSE Department19
Early Experiences with Real Social Data
 Dataset Characteristics:
 104 randomly selected students from
NJIT campus
 Many commuters  sparse traces
 Typical users provided a few hours of
data per day
 Data recorded
 Bluetooth proximity between users
 Facebook friendships

20. Distributed Systems Group CSE Department20
 81 students appear
in both collocation
and Facebook traces
 Small world
characteristics
APL=2.50,CC=0.366
vs
APL=2.98,CC=0.094
in a random graph
Early Experiences with Real Social Data

21. Distributed Systems Group CSE Department21
 Application scenario
 Students participate in community volunteering
projects
 Alice wants to invite some of them to an upcoming
activity
 Using the NJIT data set
 Facebook friends (FB): <facebook, 0.1>
 Collocation 45 minutes (CL.45): <volunteering, 0.1>
 Collocation 90 minutes (CL.90): <volunteering, 0.2>
 A neighborhood() request finds students
 A social_strength() request quantifies the importance
of the edge between Alice and a returned student
Early Experiences with Real Social Data

22. Distributed Systems Group CSE Department22
Neighborhood Function Results

23. Distributed Systems Group CSE Department23
Social Strength Function Results
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
1 2
SOCIAL HOPS FROM SOURCE
SOCSVALUE
CL.45 or FB CL.45
FB CL.90 or FB
CL.90 CL.45 and FB
CL.90 and FB

24. Distributed Systems Group CSE Department24
Discussion: Geo-Social Sensors
 Lots of challenges in building a reliable social sensor: must
determine label and weight of input
 Possible solutions for finding label:
 Mine text for keywords (emails, sms, blogs, etc)
 Reverse geo-coding to find where located and/or
collocated
 Use of a label ontology supplied by GeoS to maintain a
consistent dictionary of labels across different sensors.
 A sensor should dynamically calculate the weight of a user
interaction, considering:
 History of user social activity, by aggregating
frequency, time duration, time in-between activity
instances, etc.
 User’s interests
 “Familiar strangers” versus active social interaction

25. Distributed Systems Group CSE Department25
Discussion: User Privacy
 Perhaps the most important challenge
introduced by aggregated information
from multiple social sensors.
 Using and enforcing user policies on
what data can be collected and used
(particularly from mobile devices) is
necessary for adoption.
 Unfortunately, even if social data are
encrypted and well protected, personal
information can still be exposed by
aggregate or indirect measures (e.g.,
node degree in a graph).

26. Distributed Systems Group CSE Department26
Decentralized GeoS

27. Distributed Systems Group CSE Department27
Decentralized GeoS
 Store social information on distributed
nodes (DHT-based infrastructure)
 Use ACLs and PKI encryption to restrict data
access only to trusted users and services
 Experiments on PlanetLab to evaluate the:
 costs of inferences on an Internet-connected
distributed social graph
 effect of mapping information of socially-
connected users onto the same peer
 costs of socially-aware ACL maintenance

28. Distributed Systems Group CSE Department28
Thank you!
Questions?
nkourtel@mail.usf.edu