Key concepts
Social applications revolve around people and their relationships. OpenSocial provides a standard way for websites to expose their social graph and more. Seeing the activities of other people helps you stay up to date with your friends, and allows everything from resumes to videos to spread virally through the graph. OpenSocial also provides a way for application data to persist on a social networking site, as well as specifying the different ways that an application can be viewed within an OpenSocial container.
People
It's people! Social graphs are made out of people! People are a fundamental part of social networking software and the OpenSocial API. The Person object provides access to a user's information. Part of this information is stored in the user's profile and, depending on the site, can include anything from "favorite TV shows" to "5 things you'll find in my bedroom." The other important user information is the set of connections they have in the social graph and this is covered in the Relationships section.
There are two Person objects that can be requested directly—the VIEWER and the OWNER. To understand the distinction, imagine you're checking out a coworker's profile on Orkut. In this case, you are the VIEWER and your coworker is the OWNER. It's also common to view your own profile, in which case you are both the VIEWER and the OWNER, and some applications may choose to handle this case differently. OpenSocial also provides for the case of anonymous viewing, where the gadget will not be able to access the VIEWER's information.
The API Reference contains more detailed information about the Person class.
A note about user IDs
One of the pieces of data that is always returned with a Person object is the user's ID. 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 IDs with a domain name and separator to create globally unique IDs (e.g. "orkut.com:34KJDCSKJN2HHF0DW20394"). Note that there will likely be a size limit placed on user IDs to help manage storing IDs in a database.
Relationships
The ability to create relationships is what turns a multi-user application into social software. Being able to share information and interact with friends changes the dynamic of user experience—you're engaging with people, not software.
There are two collections of Person objects that can be requested directly—VIEWER_FRIENDS and OWNER_FRIENDS. In the case where you're checking out a coworker's profile, requesting VIEWER_FRIENDS will return the set of users that are friends with you, while requesting OWNER_FRIENDS will return the set of users that are friends with your coworker. Logically, if you're viewing your own profile, VIEWER_FRIENDS and OWNER_FRIENDS will be the same set of users. Also, if the container support anonymous profile browsing, then the application won't be able to access the set of VIEWER_FRIENDS.
Note that OpenSocial makes no assumptions about the relationship between VIEWER and OWNER. The VIEWER and OWNER could be friends, but if you're looking at a stranger's profile, there's no relationship between you, the VIEWER, and them, the OWNER.
Activities
Since we can't be online all the time, it helps to have a record of what our friends have been up to, so long as your friends want to share that record. Seeing how other people are interacting with a social application also allows you to learn new features and uses of the application, so activity streams are one of the major drivers for organic growth of applications.
OpenSocial exposes activity streams, which are a collection of actions a user has taken in the context of a given container. These activities can include interaction with the container itself, such as updating your profile or installing a new gadget, or interaction with an OpenSocial application, such as sending your friend a virtual gift or setting a new high score in a game.
Activity templates allow application developers to define messages with placeholders for pieces of applicaton or user data. This separation of data and presentation allows multiple activities to be combined into activity summaries—consolidated bundles of activities that let users know what their friends are up to without having to wade through a flood of messages.
The API Reference contains more detailed information about the Activity class.
RSS