There is a lot of talk about “Open” due to Facebook’s OpenGraph announcement and their new “like anything” concept. Many people have been complaining about these announcements mainly because of the way that Facebook talks about these ideas. When Facebook talks about the OpenGraph, they include the Facebook Like button and the Facebook page administration. This can be seen on their developer documentation for the OpenGraph. However, the open graph is actual an open protocol, with its own home, that anyone can adopt. The OpenGraph Protocol does not include the like button or page administration concepts. Even the developer mailing list shows that people are a little confused.
When you have people like Chris Saad and Dave Winer talking about something, you know you need to pay attention. They seem to be talking about the same thing, but taking different angles of attack. They also seem to throw “likes” into the discussion as well, further confusing people. However, they both have some very good points. First, Chris talks about interoperability:
Data portability is no longer enough. We must raise the bar and start to aim for Interoperable Data Portability. Interoperability means that things work together without an engineer first having to figure out what’s on the other end of an API call… Just like every site on the web today can have its own web server, every site should also have the choice to host (or pick) its own social server. Every site should become a fully featured peer on the social web.
Technically speaking, any site that implements the OpenGraph Protocol, a data specification, has interoperable data portability. Any service may read the open graph data and act upon it. Chris was focused more on the data portability aspect, whereas Dave was focused more on the graph consumer in his post on services being replaceable:
Think of it this way. There is no root to the web. There is no home page. No place you have to go first before you go anywhere else. Same idea — there shouldn’t be any center to the graph-of-everything. That’s where the bar should be set. And Facebook ain’t even in the ballpark… Anyone should be able to operate a graph. And of course we should be able to point into graph.facebook.com, and not just at the root, but into any bit of data they expose.
Technically speaking, any site may be a consumer of the data of the open graph. The difficulty is knowing how to get at the data, which is Dave’s real target. Should we have a graph.domain.com specification? The key here is that Dave is talking about specifying an API for the graph for any data that a site may expose. This is a much larger vision of what the OpenGraph could become.
So, how do we merge the data specification of the OpenGraph with an action oriented API that avoids the “center of the graph” problem? First, look at the OpenLike Protocol that was created in response to the Facebook Like concept. This is really an open specification of the type of functionality that is currently provided by ShareThis and AddThis. This also does not really do the same thing as the Facebook Like. As a web content producer, this really does not help me much either. I would still be sending data to various services that would become the “center of the graph”.
One specification does support likes and various other actions. It could easily support the data specification for the OpenGraph, and already has much of what is needed. It is already supported by Facebook, MySpace, Windows Live, Google Buzz and many other services. I am talking about the ActivityStreams standard. This could be used to support all sorts of functions for a web site. ActivityStreams also has a very active mailing list if you want to get involved.
While I can appreciate what the OpenLike Protocol is trying to do, we do not need to reinvent the wheel. What we need to do is gather more support for ActivityStreams and help with the general implementation of them. How can a content producer use ActivityStreams? Can we make it as simple as possible for someone to plug this functionality into a WordPress blog? Can the data be stored locally or at least have the information stored at the service of our choosing? If we can really push this forward, many of the Facebook widgets become unnecessary. We could even have third party services built based on ActivityStreams to provide statistics and analysis about the activity.
What can you do to further the progress of ActivityStreams?