OpenSocial: First Impressions

by Robert Cooper

Google's much hyped OpenSocial API finally appeared on code.google.com. For the most part it is "Yet Another GData API." Which is good, and bad. Good in that people pretty much understand it. Bad in that it seems really half-baked to me.

Let's start with the sample friends list. This would live somewhere like: http://{domain]/feeds/people/{person-id}/friends


<feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005'>
<id>http://sandbox.orkut.com:80/feeds/people/14358878523263729569/friends</id>
<updated>2007-10-28T21:01:03.690Z</updated>
<title>Friends</title>
<link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://sandbox.orkut.com:80/feeds/people/14358878523263729569/friends'/>
<link rel='self' type='application/atom+xml' href='http://sandbox.orkut.com:80/feeds/people/14358878523263729569/friends'/>
<author><name>Elizabeth Bennet</name></author>
<entry>
<id>http://sandbox.orkut.com:80/feeds/people/02938391851054991972</id>
<updated>2007-10-28T14:01:03.690-07:00</updated>
<title>Jane Bennet</title>
<link rel='thumbnail' type='image/*' href='http://img1.orkut.com/images/small/null'/>
<link rel='alternate' type='text/html' href='http://sandbox.orkut.com:80/Profile.aspx?uid=574036770800045389'/>
<link rel='self' type='application/atom+xml' href='http://sandbox.orkut.com:80/feeds/people/02938391851054991972'/>
<georss:where>
<gml:Point xmlns:gml='http://www.opengis.net/gml'>
<gml:pos>51.668674 -0.066235</gml:pos></gml:Point></georss:where>
<gd:extendedProperty name='lang' value='en-US'/>
<gd:postalAddress/>
</entry>
<entry>
<id>http://sandbox.orkut.com:80/feeds/people/12490088926525765025</id>
<updated>2007-10-28T14:01:03.691-07:00</updated>
<title>Charlotte Lucas</title>
<link rel='thumbnail' type='image/*' href='http://img2.orkut.com/images/small/null'/>
<link rel='alternate' type='text/html' href='http://sandbox.orkut.com:80/Profile.aspx?uid=5799256900854924919'/>
<link rel='self' type='application/atom+xml' href='http://sandbox.orkut.com:80/feeds/people/12490088926525765025'/>
<georss:where>
<gml:Point xmlns:gml='http://www.opengis.net/gml'>
<gml:pos>0.0 0.0</gml:pos></gml:Point></georss:where>
<gd:extendedProperty name='lang' value='en-US'/>
<gd:postalAddress/>
</entry>
<entry>
<id>http://sandbox.orkut.com:80/feeds/people/15827776984733875930</id>
<updated>2007-10-28T14:01:03.692-07:00</updated>
<title>Fitzwilliam Darcy</title>
<link rel='thumbnail' type='image/*' href='http://img3.orkut.com/images/small/1193603277/115555466.jpg'/>
<link rel='alternate' type='text/html' href='http://sandbox.orkut.com:80/Profile.aspx?uid=14256507824223085777'/>
<link rel='self' type='application/atom+xml' href='http://sandbox.orkut.com:80/feeds/people/15827776984733875930'/>
<georss:where>
<gml:Point xmlns:gml='http://www.opengis.net/gml'>
<gml:pos>53.017016 -1.424363</gml:pos></gml:Point>
</georss:where>
<gd:extendedProperty name='lang' value='en-US'/>
<gd:postalAddress/>
</entry>
</feed>


So, what have we got here? Well, it is awful little. Title is obviously the person's name. We have a gd:postalAddress field for an address, a georss:where to locate them on a map (this can be a specific location, or just a city pointer), and a thumbnail. That's it.

This is what the People Data API specs:




























































Property Type Description
Name atom:title The desired display name for the user
Image link atom:link With rel="thumbnail", a small image URL to represent the user
Profile URL atom:link With rel="alternate", the standard profile URL representing the user
GeoLocation georss:where Geographic location of the user. This may be approximate, or rounded off to the nearest city.
email gd:email Email address(es) for the user
IM gd:im Instant messaging adress(es) for the user
Address gd:postalAddress Address(es) for the user.
Phone number gd:phoneNumber Telephone number(s) for the user
Key value parameters gd:extendedProperty As different social networks and other sources of People data have many different named fields, this provides a way for them to be passed on generally. Agreeing on common naming conventions is to be decided in future.



That is really not much. For instance, Given Name and Sir Name aren't broken out into separate fields. That alone can make importing into a standard address book problematic. Secondly, the link rel="thumbnail" use is COMPLETELY retarded. It gives no real information, and doesn't really apply. I don't understand why Google didn't use MediaRSS for this, which supports multiple representations of the same media element, contains size information, etc. They already use MediaRSS on Google Video, so I can't imagine it is a religious issue.

Also, hand-wavy stuff like this always makes me nervous:
As different social networks and other sources of People data have many different named fields, this [gd:extenedProperty] provides a way for them to be passed on generally. Agreeing on common naming conventions is to be decided in future.


Name-value pairs seem really inadequate here. I don't understand why we can't, much like the APP specification instructs, say that foreign markup of any nature will be preserved. If I want to sync a contact between two different services, that contact information should simply preserve whatever markup the other services wish to include. Moreover, if I wanted to do something like embedding (x/v)Cards in the entries, seems like that should be just fine.

Finally, it seems to me that doing GoogleAuth everywhere for this is less than optimal. OpenID would be much better and would encourage more adoption at the bottom level of the tech food chain -- not MySpace and Six Apart, but Joe Blow's open source project. But it all goes back to the root of the problem here:

Google didn't design a spec for interoperability of social networks as much as they built an API for dealing with Google. I don't think this is what people really wanted here. Aside from the fact that it works on the presumption that everyone is going to clear everything through Google, it is going to require a whole lot of user understanding to make this data really portable.

For instance, it seems to me there should be part of the specification that says profile pages have link rel="opensocial" pointing to the users individual feed. That is easy to communicate to the user that they can point at a buddy's page to add them as a friend. If that page also had an OpenID link on it, then cross registration outside of the Googleplex would be easy. If the Microsoft SSE extensions were used, then it would be easy for me to maintain references to my accounts on other systems from each other, so with Alice imports her Orkut contacts to MySpace, MySpace can find the myspace <id>'s from people on Orkut with dual membership and resolve that automatically. There also doesn't seem to be anything implicit in the auth structure for *requesting* access to profile information. It is common to restrict your exposed profile data to people who are your friends. Having links between profiles on different services -- presumably with something more like OpenID auth to establish profile ownership -- would allow for this; you could import my full information from my MySpace page into Outlook if you were my friend on Orkut.

In short, I am sure OpenSocial will make a dent in something. But it doesn't seem to be solving the "Give me a truely portable contact list and identity" that I would really like to have.

7 Comments

Patrick Carroll
2007-11-02 10:54:16
Under "Hosting OpenSocial Apps", we see:


"Your website can host third party OpenSocial apps integrated with your site's social network. There are 2 steps to doing so -- become a gadget container, and implement the OpenSocial Service Provider Interface (SPI)."


Further down we see


"The OpenSocial website development kit will include full SPI documentation. It will provide open source reference implementations for both client and server components."


Key word: "will". I'd wait for the present tense.

cooper
2007-11-02 10:59:17
Key word: "will". I'd wait for the present tense.

Yeah, that is fair. Honestly, though, building a basic implementation here isn't that hard. People know how to build rest-y services, and I could build an implementation of the data services on Propono in pretty short order.
RYK
2007-11-03 05:33:22
is the aim of opensocial 100% user data portability, or is it more of a benefit to application writers: common platform?


If the latter, why doesn't facebook simply release their SPI and win the battle in seconds?


Mohandas Hakimchand
2007-11-03 08:38:37
Why the developers or corporations should depende on Google?building your product or service on some third party does not make sense in long term
MH
Dan
2007-11-05 05:02:59
"Secondly, the link rel=”thumbnail” use is COMPLETELY retarded. " - you actually get paid to write like this? Thanks for the well-thought out, insightful commentary.

2007-11-05 13:01:47
"Given Name and Sir Name aren’t broken out into separate fields"


Surname.

romain
2007-11-07 03:46:30
"For instance, Given Name and Sir Name arenít broken out into separate fields."


These fields are way not universal (though somehow western-like; hispanic or scandinavians for instance, have naming rules that do not fit). So basically, having a single field "Name" is not that stupid; depending on an other attribute, this name may be "splitted" and interpreted differently by software; see http://rishida.net/blog/?p=100 (Personal names around the world 1).


But that may not be the reason here there is a single field.


However, I agree with you that it looks like too much a Google-centric API to be really of interest in front of Facebook. There's still room for a true "open" spec here; that could be build upon this very one.