Welcome to OpenSocial

Updated: April 04, 2008

OpenSocial has been embraced by most of the largest social-network providers, including Friendster, hi5, LinkedIn, MySpace.com, Ning, Plaxo, Salesforce.com, SixApart, XING and Google's own orkut. Notably absent from this list is Facebook, which has implemented its own proprietary platform.

OpenSocial appeals to three distinct audiences. It lowers the friction for users who are already suffering from social-network fatigue because they get more apps without having to register for each one or re-create their network of friends with every new service. For existing social networks that are already concerned about confronting Facebook's successful developer platform, OpenSocial provides a way to bring additional functionality to the network.

The appeal for developers is clear. An open Web API means that you don't have to learn proprietary markup languages and APIs for each network that you want your app to run on. The problem is similar to having to write for all of the different OSes and platforms out there, but multiplied a hundredfold. Write the app once, and get access to hundreds of networks.

What Are Social Applications?

As simple as OpenSocial is, it may require a paradigm shift for developers who are just getting their heads wrapped around writing apps that run inside a browser. Originally, the Internet was about communication, but it quickly shifted to a publishing model where people would go to a particular Web site based on their interest in a particular topic.

"As more and more people move online, the groupings are less based on affinity to a topic and more based on their relationships and affinity with their colleagues," said Google developer advocate Kevin Marks. "All Web sites are enhanced by social interaction. Being able to tap into that and lower the barrier for entry is what OpenSocial is all about."

Just as HTML and CSS create a layer of abstraction around presentation, the OpenSocial APIs do the same for the social interaction that is represented by friend adds, photo uploads or updates to a user's online profile.

A few definitions are in order. OpenSocial calls the social networks "containers," and allows developers to build "apps" that are embedded within and run on these networks. Anyone who uses a social network like Facebook is already familiar with apps built by iLike, Flixster, RockYou and Slide Inc. that enhance the platform in various ways. But OpenSocial apps are more than mere widgets; they provide deep hooks into a user's social graph.

This approach, with containers, and apps is quite similar to that of the Facebook Platform. The key difference here is that any social network can be a container, whereas with the Facebook Platform, the only possible container is Facebook itself.

With the Facebook platform, apps are written using the site's proprietary languages and APIs, such as FBML (Facebook Markup Language) and FQL (Facebook Query Language). By contrast, OpenSocial apps are written using standard HTML and JavaScript. This distinction is important, because what Facebook has done is essentially created an alternative to the existing Web as a platform, albeit one with more social interaction baked in. According to Marks, one of the main goals for OpenSocial was to extend the Web in the direction of social networking while still using Web standards.
Social Graph API

A related but separate initiative is Google's Social Graph API. The Social Graph shares one of OpenSocial's goals: reducing the need for users to add connections each time they add a new Web service. This has lead to some confusion among developers, who are wondering which one to use when trying to tap into these connections.

To understand the difference, you must first make the distinction between the kind of public declarations of connections made on blogs and Twitter and Flickr feeds and the more private relationships expressed on a social network like MySpace.com. A blog provides a public URL that can be indexed by Google's Web crawler, while a MySpace.com profile is available to only those users that have been provided with access. In the first case, the URL itself is a representation of that person. By using the Social Graph API, developers can tap into the publicly declared connections that are already available on existing services. The API returns Web addresses of public pages and publicly declared connections.

Technically speaking, the Social Graph API uses open Web standards for describing connections between people such as XFN (XHTML Friends Network) and FOAF (Friend of a Friend) markup. XFN is a micro-format that provides a simple way to represent relationships by adding one or more keywords as the "rel" attribute to their links, as follows:

By putting a human face on linking, XFN uncovers the human relationships behind these links.

FOAF provides a machine-readable ontology that describes persons, activities and relationships. FOAF is an extension to RDF (Resource Description Framework) and is defined using OWL (Web Ontology Language). Each profile has a unique identifier (for example a person's email address, Jabber.org ID or a URL to a blog).

With both XFN and FOAF, humans must explicitly describe their relationships to others in their network. Therein lies both languages' biggest strength and weakness. By providing a standard means of doing this that is easily understood by the people with the greatest access to this information, it ensures that this information is both accurate and easily portable. In addition, the languages return control over this information to the users. By providing a layer of abstraction on top of the social graph, XFN and FOAF allow users to move easily from one social network to another and freely combine them as they see fit.

At the same time however, XFN and FOAF are incomplete. The Social Graph API provides a good start, but because it is limited to only that data that is expressed publicly, it can represent only a fraction of the people online. Also, more active, early-adopter types tend to have blogs or use a service like Twitter. The majority of the information about one's Social Graph remains inaccessible.

Featured Research
  • 16 Mistakes to Avoid When Buying a Phone System

    Purchasing a phone system for your business is a major investment. With the average business changing phone systems only once every seven years, it’s important to make the right decision. more

  • 2017 Video Conferencing Trends

    New advancements are also making video more beneficial to a greater range of business areas including marketing, HR, and internal operations. Many solutions are economical, easy to use, and very effective at making communication more personal. more

  • [Infographic] Top 11 VoIP Vendors

    A good VoIP provider will offer additional benefits as well, but many first-time buyers find assessing each option to be difficult. Nevertheless, this is an important step in the buying process because a substandard provider can easily waste both your time and money. more

  • Work Smarter Not Harder with Business Intelligence

    While this may have been true at one time, the days of BI requiring a dedicated team of experts to implement are over. Self-service solutions are making it possible for everyone, including small, local businesses, to easily implement BI in their decision making process. more

  • Best Practices for Contact Center Quality Assurance

    A contact center often brings about a prospect’s first real-time interaction with your company. As such, if it’s not a positive one, they’ll likely look elsewhere for help. With 69% of Americans more inclined to recommend a company to friends and family after a positive customer service experience, you’ll need to exceed expectations on the following fronts. more