In an e-mail message announcing the Web 2.0 Summit 2010, John Battelle and Tim O'Reilly ask a rhetorical question: "Who owns the social graph?" They're using the question as a vehicle to generate interest in the Web 2.0 Summit, but it's an excellent question in and of itself.
There are Many Social Graphs
Facebook represents but one social graph. In the Facebook graph, people are symmetrically linked as friends. Symmetrical just means that if you're a friend to me, then I'm also a friend to you. There are other links in the Facebook social graph, too, created when people comment on posts, or when they Like a web page, etc.
Twitter has another graph of social importance. In the Twitter graph, people follow each other. The follow relationship is asymmetrical, meaning that I might follow you, but you need not follow me. In the Twitter graph, people also issue tweets, and tweets can contain pointers to (URLs for) web pages.
LinkedIn has another rich social graph, in which people are linked in various ways, including having worked together, or writing a reference for one another (the latter relationship often suspiciously symmetrical!).
What Does an API provide, and Does an API Determine Control?
Facebook, Twitter, and LinkedIn all provide Application Programming Interfaces (APIs) that allow third-party websites and programs to access and manipulate the social graph data that those services contain.
Different service providers offer different operations in their APIs. In general, when one is talking about access to records containing data, the four basic functions are: create, read, update, and delete (often remembered through the simple but unfortunate acronym, CRUD).
It's clear that companies such as Facebook, Twitter, and LinkedIn hold the "master copy" of social graph data in persistent storage. But that doesn't mean these companies truly "own" it.
If a full set of API operations is provided, then a third party could extract all social graph data and claim it as their own. Clearly, that doesn't happen in reality, and there are various programmatic and legal constraints in place that prevent it.
With Facebook, for example, the API, as authorized against any single user, provides programmatic access to the friends of that user, and to the names of the friends of those friends, and that's the end of the road. Using the API, it simply isn't possible to wander off into the full Facebook social graph, collecting friend relationships willy-nilly.
Twitter provides greater access. A program that accesses the Twitter graph through the Twitter-provided API can follow links, transitively, forever. But practical limits are enforced on how many calls can be issued in a given amount of time. This effectively throttles third-party access. (Different levels of API access are granted by Twitter, all the way up to the "firehose," for a select few.)
So it's easy to see that the companies that host persistent social graphs are walking a delicate balance, between trying to make it possible for third-party applications to offer valuable new services on top of social graph data, and trying to ensure that they retain long-term control of that data.
An API can be Turned off -- Does That Imply Control?
Each API call into a social graph provider must include a token that identifies the calling party. This is an ID of sorts, and a provider, based on that ID, can reject any given API call. The provider hosts the data and the use of an API as a gateway means that any third party can be denied at any given point in time.
One concern, at least in the abstract, is that a third party would use an API to systematically extract all social graph data, and then run away, trying to build a valuable service on top of the data that it has obtained. Could this happen? Would a service provider need to deny API access in order to prevent it from happening? Unlikely.
A social graph is a dynamic data structure, so it's effectively impossible to build a copy of the graph that's useful long-term. There's an underlying rate of change in the social graph itself -- it's constantly evolving. An API provides a snapshot into what the graph looks like right now.
The social graph is different only minutes after an API call is made. So having API-based access to the social graph doesn't make it easy to create a working copy of the graph.
While the ability to deny API calls might suggest control of the underlying graph, in practice, it's the fact that the graph is alive and dynamic that makes it impossible for a third-party to use an API to wrest control away from the social graph service provider.
So, Who Owns the Social Graph?
A social graph is created and maintained in a rich ecosystem of interaction and services, and an API is always a trailing window that can be used to look into where the graph has been. But having access to that window doesn't mean that a third party can wrest control away from the provider, and the provider doesn't need to deny API access as a way to maintain control.
So, provided that Facebook, Twitter, and LinkedIn (and others) continue to provide valuable and well-differentiated services to their users, they will continue to own their individual social graphs. It's the valuable services that they provide that make their graphs dynamic, and it's graph dynamism that prevents others from taking control (API or not).
But what of the meta-graph -- that is, the social graph that includes all (or at least, many of) the others? If you're like me, then you have an account in Facebook, at LinkedIn, and at Twitter (and probably many other places, too!). Is it possible to define a service that delivers value to you, by "gluing together" your various disparate social graph selves, so that you have an integrated view of your various social networks? Yes, it is.
A few start-ups are already trying to provide such integrated social graph access, and many more are coming. The key question is, what is the user-facing value proposition, and can that value proposition be delivered to a user through the existing graph-provider APIs? If so, then it's possible to imagine that some future company can wrest control away from the current graph-owners.
Control lies with those who provide value to a large number of end-users. Currently, that control is centered with the individual companies that provide specific services around their individual social graphs. But each of us has a presence in many of those social graphs.
So the near future holds promise for services that offer user-facing value that spans multiple social graphs. This will be an interesting area to watch for developments!