Tuesday, February 12, 2008

Information sink vs information source

How Sticky Is Membership on Facebook? Just Try Breaking Free - New York Times

Another example of how most applications act like information sinks. It's easy to enter your information (data about you), but once you do, you lose control. The Facebook application (like almost any other online application) is an information sink.
Image via http://images.macworld.com
To me it seems the only approach to preserve control over your data is to leave those applications alone. That's why I'm not on Myspace, Facebook or others (Linkedin being the exception, for some reason).

Ideally, I would like to have the ability to create an information source, totally under my control, in which I design and edit my profile. A generic protocol for addressing and disclosure would then allow other applications and people to use this information source for many different applications (which would then basically become views on my data, and that of others in the aggregate).

What do you think?

Tuesday, February 5, 2008

DataPortability and the Web Worker

One of my favorite blogs, Web Worker Daily, struck a nerve when posting about the DataPortability initiative. I couldn't resist to comment.

Friday, January 11, 2008

DataPortability - bad name for a real problem

Image: (c) corbis
It's about you

The recurring theme in social web data is that the data concerned is about an individual (ie. you). Anything that describes (a part of) you or your actions or preferences or you name it, qualifies to be part of your 'profile'. It doesn't matter if you typed it in yourself, or if it is generated by some system. (As long as something pertains to you, represents you, it should be under your control. I'm taking an extremely user- or identity-centric approach here).

Currently almost any data describing you is not under your control. See The Profile Problem of which the Scoble vs Facebook case is an example (not the latest, methinks).

Let me be clear: I totally agree with the problems that DataPortability tries to solve. Only the name of the project is misleading to say the least.

The name Data Portability (and some of the things I've read on their website and forum) gives me the feeling that they want to be able to extract and import 'user data' from and into various existing social-web applications, just like Scoble did. That's a nice problem to solve, but it all depends on what level of abstraction the standards are formulated.

Let's do a thought experiment, Imagine a less-than-world-wide web where pre-existing publication platforms were hosting content, each in its own proprietary way. At some point the need for inter-operability (linking) and re-usability of this content becomes apparent.

Thanks to Tim Berners-Lee, and lucky for us, we don't have this situation on the current world-wide (webpage) web. We're not porting documents from one web-server implementation to the other, and we don't need or want standards to do so. Instead we have the HTML standard for the document format, the HTTP protocol for accessing and creation, and the URL for addressing.

These are key components. But on the social web, we do have this situation.

The problem isn't then that we can't port or migrate data (we really shouldn't be wanting to go that way), the problem lies deeper in that there aren't any standards for representing, addressing and manipulating this type of content.

Similar to the standards that make the world-wide web so successful, I sincerely hope that the DataPorters want to come up with a similar addressing standard for identities and for individual attributes. Already OpenID covers the part of the solution.

Once identities and specific attributes are uniquely addressable, data at these addresses should be in a standard document format (like HTML documents which resides at url addresses, 'attribute documents' should reside at attribute-url's). I would like to have an addressable document in a standard document format for each of the attributes that are part of my self-representation. (Unlike web-pages, these attribute-documents shouldn't be automatically world-readable, the documents themselves should include disclosure settings, and part of the access protocol should be the decision to disclose or not, depending on the 'requesting party'.)

It follows then that we also need a protocol for sending messages to create, retrieve, update, remove and share (disclose) these attribute-documents (defined by their unique addresses); HTTP does this for viewable documents and we should have something similar for identity-centric attribute documents.

Once the standards are there at the right level of abstraction (the attribute level imho), the rest is easy. You could implement a Facebook in no time, and it would be inter-operable with any other such system (no need to shovel data to and fro).

Conclusion

It seems to me that trying to make current proprietary social-web applications inter-operable after the fact, by devising a standard at the application level, is a waste of effort. Too bad we have existing applications without standards, but this still leaves us with the need for low-level standards for the identity-attribute domain. Once we have that, data portability is a non-issue.
Creative Commons LicenseExcept where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 License