Chapter 1 Overview

The goal of social applications is to build online communities of people who share interests and activities, or who are interested in exploring the interests and activities of others. The Sun Glassfish SocialSite software adds social features to existing web applications by providing a server to manage the social graph, as well as a library of social widgets that can be added to an existing web page.

About Social Graphs

With a typical social application such as MySpace, individual users can upload a picture of themselves, create their profile, and designate other users as "friends". Such social applications also offer the ability to create groups that share common interests or affiliations, and track individual/group activities.

Social applications use a social graph that is a global mapping of all users and how they are related such as:

• Personal profile information including contact information, personal tastes, body type, work history, or education

• Relationships between people

  • Friends

  • Business contacts

  • Membership in groups

• Activities for each user

  • Changes to the status or properties

  • New content created by other users

  • Message notifications from other others

Social applications may require a dedicated container (or server) the to manage the various profiles, friends, groups, and activities in the social graph. The OpenSocial specification allows social applications to manage social graphs with a set of common application programming interfaces (API) that expose methods to information about people, their friends, and their data. The OpenSocial specifications usually are used to develop social applications from inception to deployment.

In contrast, the SocialSite software is an end-to-end solution that adds social networking features to existing web applications by providing a server to manage the social graph, as well as a library of social widgets that can be added to an existing web page. Since the SocialSite software already complies with the OpenSocial specifications, there is no need to implement the REST API and the JavaScript API from scratch to create a social networking application. However, the SocialSite software does extend the OpenSocial REST API and JavaScript API specifications to provide a complete solution.

People

The OpenSocial specification defines the Person object to store information specific to a user. Part of this information is stored in the user's profile (such as hobbies and contact information). The other important user information is the set of connections with other users in the social graph and this is tracked as relationships.

The user ID must be alphanumeric (A-Za-z0-9) and must uniquely identify the user in a container. This standardization is intended to allow for prefixing user IDs with a domain name and separator to create globally unique IDs. Refer to Authentication Delegationfor more information on how the SocialSite software extends the OpenSocial specification to provide unique user identities.

There are two Person objects that can be requested directly from an OpenSocial container: the VIEWER and the OWNER. The VIEWER accesses the user profile of another user (who would the OWNER). Likewise, a user can act as both VIEWER and OWNER when the user's own profile is updated.

The standard OpenSocial specifications do not support creating and updating user profile data. Likewise, the standard OpenSocial specifications do not give you any control over who can see which parts of your profile or activities. The SocialSite software provides extensions to manage user profiles (User Profile Data Extensions) and limit access to user profiles (Profile Privacy Settings Extensions).

Relationships

There are two sets of relationships that are defined in OpenSocial: VIEWER_FRIENDS and OWNER_FRIENDS. In the case of accessing another user's profile, a VIEWER_FRIENDS request will return the set of users that are friends with you, while a OWNER_FRIENDS request will return the set of users that are friends with your coworker. If you're viewing your own profile, VIEWER_FRIENDS and OWNER_FRIENDS will be the same set of users. The OpenSocial specification makes no assumptions about the relationship between VIEWER and OWNER.

Note that the OpenSocial specification does not distinguish personal relationships. The VIEWER and OWNER could be friends, but if you're looking at a stranger's profile, there's no relationship between the VIEWER and the OWNER. Here are types of personal relationships that may be supported in social applications:

• A one-way relationship from one person to another person that is not reciprocated.

• A two-way relationship from one person to another that is reciprocated.

• A mutual relationship where two parties have agreed on some shared item of information about the relationship (work for the same manager).

The standard OpenSocial specifications do not support the process of requesting and negotiating some form of social relationship with another user. The SocialSite software provides extensions that manage personal relationships (see People and Friends Extensions).

In addition, the standard OpenSocial specifications do not support any group creation, management or invitation capabilities. The SocialSite software provides extensions to create and manage groups (see Group Management Extensions).

Activities

The OpenSocial specification has the notion of activity streams, or collections of actions that a user has taken in the context of a given container. These activities can include interaction with the container itself, (such as updating a profile) or interaction with an OpenSocial application. Activities can be separated into data and presentation so that multiple activities can combined summaries or bundles that let users know what their friends are up to without having to wade through a flood of messages.

The SocialSite software provides extensions that allow message notifications for individual and group activities (see Messaging ).