I’ve been waiting to write anything about OpenSocial until there were published API’s (Application Programming Interface) and now, thanks to this link, we now have our answer to what OpenSocial will mean for the community of social media developers and network providers. First, I am very pleased that Google has put forth an effort to standardize the “fabric of the web” so that developers will have one common and consistent API to work with. As usual, google has made a very smart business decision to sign up FaceBook’s competitors to support their SPI (Service Provider Interface). This may force FaceBook to support their own home brewed API as well as OpenSocial or throw theirs out if OpenSocial becomes the de facto standard (which Google is hoping for).
So what does this really do for you the user of social networking applications/websites. Well, if you hate to add your personal information into every website you use over and over again, I’m sorry to say you’re still going to have to do it. To be fair, Google states,”Important: The OpenSocial People data API hasn’t been released yet; this document is a preview of the developer’s guide that we’ll publish when we release the data API. All of the details are subject to change, but this preview should give you a general idea of what the API will be like”.
Honestly, not much information can be transferred across sites using these API’s. Here are the 8 pieces of information that you will never have to enter into another social networking website again:
| 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. |
Notice the last row in this table “gd:extendedProperty” - This is where google will extend the API in the future. For those of you who are not programmers, this is a common convention to use to extend an API in a “reasonable” way. We can only wait and see if this becomes a “dirty closet” to stuff other data or is truly used as an extension point in the future.
What does this mean for SciLink? That’s a great question and one that we’ve been contemplating for a few days. First, we are extremely excited about this move by google as our platform was designed from the ground up support developers through an external API. In fact, the entire SciLink website is written using these API’s so that any web developer can plug into and use SciLink functions. We have hesitated to release these developer modules because they are non-standard, undocumented and proprietary to our platform. With the introduction of OpenSocial, we now have a clear path to support a developer community who would like to extend SciLink with new functionality. To that end, we will be actively and aggressively supporting the OpenSocial SPI when it is fully documented and released. This will open up our platform to developers using a well thought out, well documented and most importantly, standard API to develop your applications.
If you’re not convinced, think of it this way: There are a limited number of wireless providers out there that you can choose from: Verizon, Sprint, ATT etc. In Google-Speak these are social networking “containers”. You have a large number of cell phone manufacturers to choose from when you sign up for a network like Motorola’s Razr etc. These are like the application you will be writing using OpenSocial each one will have interesting features etc. that you will use to differentiate yourself from the other application providers. OpenSocial is the protocol that the providers “speak” so that you, the customer, can switch to another provider without having to throw out your phone if/when you decide to switch providers so you, the customer, should be pretty happy when you switch to another social network and (supposedly) applications that you love can come along with you. As always, the devil is in the details.
That wraps up our thoughts on OpenSocial for now. More to come.