Abhishek Tiwari

As you know from few posts on this blog, I am a huge supporter of user’s owning their social graphs. Over multiple posts, I have been laying out the need for a consolidated service, which hosts the graph (along with identity) for a user.

Last week this discussion caught some steam with some great posts by Tim Berners-Lee and Dave Winer. Dave’s post made me think that the data ownership problem is bigger than just the graph. Theoretically a user owns all the content they generate on any of these services. You know, things like Amazon ratings, YouTube videos, etc. While I don’t see anyone having the need for getting an XML file with this content for personal use. I do see them wanting to use this data on other services. For example (from Dave’s post) one can use their movie ratings at NetFlix and use it with Vudu or share it with their friends on Facebook.

This thought process clearly reflects that there are many graphs (social or otherwise) within many dimensions of services on the web. Every new service with any user generated content is creating a new graph. I talked about the need for consolidating the access to this graph in my last post. Given the dispersed nature of the graphs it will be pretty unrealistic for any web service to physically do that. Hence in this post I am recommending a slightly different mechanism whereby we can enable an ecosystem on the web and achieve the same results. So here it goes:

Enable Web-Service Access to User Data

All services, which rely on user generated content, in any shape or form should enable a simple web-service, which hosts a XML version of user data. For example Facebook can offer web-services access to a XML file containing friends, messages etc and Amazon can provide service access to a XML file, with user wish-lists, ratings etc.

The intent is to allow access to this data by external services/applications or the user themselves. Now access to these services shall be secured and only upon authorization from the user. As this data clearly belongs to the user, these services can not claim ownership here and should expose the information in the interest of the user.

Note: W3C talks about various formats, which can be utilized for this purpose.

Establish a Single Web-Service Registry

Services supporting the aforementioned web-services scheme should be listed in this registry. The registry can support items like web-service URL, ID , data description format etc. The idea here is to create a generic repository where other applications (or user) can lookup these services. Think of this like DNS for web-services.

In this registry, each service shall receive a unique ID. This ID will be utilized while looking up the web-service resources. For all practical purposes the URL itself could be the unique key. This registry will be utilized by services/applications to find resources about other services. Think of it as the “Information Booth” of web-services.

Expand OpenID to Incorporate User’s Service IDs

Now this is the exciting part. OpenID systems should expand to incorporate user’s services. They should enable lookup of the “Service Registry” and allow user’s to configure the services they currently use (while registration or later). This will essentially enable OpenID systems to establish the relationship between users and services. Now bear in mind that this data is private and is only shared on user authorization.

This establishes the cross-web relational database of users and services. This doesn’t mean that any service having access to user’s OpenID can extract data from any of the web-services. Instead as mentioned earlier, each service is protected and user must selectively authorize access to the requesting 3rd party.

Applications and Services to Utilize Open-ID/Service Registry/Web-Service Combo

Once the relationship is established, other applications can easily take advantage of this setup. For example; the user signs up onto a new social network belonging to his local Fantasy Football club. The social network offers the user to sign up via his OpenID and at the same time requests to lookup his other services. Upon user authorization, the service can find that the user also belongs to Facebook. This triggers the application to prompt the user to import his/her friends from facebook onto this new network. Upon user authorization, the network can easily access the service registry, lookup the web-services URL and access the Facebook graph data.

That was probably a straight-forward example. However the possibilities with such a setup are endless. An application can potentially lookup any service you belong to and import data if its valuable.

Clearly such an environment allows data sharing across the services driven by user needs. The user receives the flexibility he/she needs to take their data anywhere they want and on the other hand this opens up new opportunities for application and service providers. These providers now have access to user’s data from other services, which offers them a level playing field. They can now focus on their features instead of building the graph all over again.

Accessing external data could also be used as a motivation for social services to open up access to the user content/graphs stored on their systems. I believe an entity like W3C could drive such an initiative. They could serve as the service registry for everyone.

Frankly this is what the web should be. As far as I am concerned this is a good implementation of the Semantic Web (Web 3.0) talked about by Tim Berners-Lee, where applications can understand data from other services, versus it being plain vanilla human readable HTML only.

Hope you enjoyed that post. Send in your comments and thoughts. I will be posting more in this series. Don’t forget to subscribe to the RSS feed to stay tuned.

Share This