All the applause over Google’s Data Liberation Front announcement and blogs is making my head hurt. Or maybe that’s the lack of sleep. Either way, it’s disconcerting to me that so many bright people are choosing to make much of what is just a baby step – if that - toward a much larger, much more difficult goal. After all, data without an application to interpret and make use of it is about as useful as a Netbook without a network connection.

There seems to suddenly be a lot of focus on “data” and the ability for users consumers to pack up their data and take it wherever they want. Except for people attached to their i-Thing. I think users of i-Things were approached about the concept but were unable to get past the revelation that there are other “i-Things” out there from other vendors in the first place. Regardless, the core concept appears a laudable goal and rational desire. After all, the data was probably created by the consumer and thus, by most people’s definitions, they own the data. It’s theirs, so they should be able to move it hither and fro at will. But what is “data”?

This definition seems as good as all the others, summing up what most people – at least those able to articulate in technical terms – consider data:

- (1) In computing, data is information that has been translated into a form that is more convenient to move or process. Relative to today's computers and transmission media, data is information converted into binary digital form.

Data is bits and bytes; it’s a digital representation of something else – a photo, a document, a presentation, audio, video, etc… On its own data is meaningless. Data is nothing more than a collection of 1s and 0s used for processing and storage. It isn’t anything useful until (wait for it, wait for it) an application interprets that data and does something interesting with it. It’s a representation, and nothing more.

That said, Google’s Data Liberation Front is going to free data from its products and give users consumers a way to move it, store it, manipulate it, whatever they want because, as we all agree, it’s their data. The brouhaha over data actually began much earlier than Microsoft’s already infamous Sidekick data loss, but that event is what really turned the spotlight on data liberation. Reuven Cohen of Enomaly sums it up nicely in his blog post “Google’s Data Liberation Front”. But even Reuven falls short in his analysis.

The site also points out that there shouldn't be an additional charge to export your data. Beyond that, if it takes you many hours to get your data out, it's almost as bad as not being able to get your data out at all. I would also add if your data isn't usable. For example a 1tb text file is (almost) just as bad as not getting your data at all.

The FAQ answers some interesting questions including that of Data Standards saying "We're working to use existing open standards formats wherever possible, and to document how we use those formats in a clear simple manner."

Personally, I applaud this move by Google, lets hope others in the cloud space follow Google's lead.

Reuven gets to the heart of the problem, “a 1tb text file is (almost) just as bad as not getting your data at all” but then seems to accept that “open standards formats” is a good enough answer to the problem. In some cases, in some very few limited cases like those where the data represents documents and photos and e-mail, those standard formats are enough. Even I am satisfied with that. But for data for which there is no “standard format” this isn’t enough, and it’s the latter half of the statement from the FAQ that becomes relevant: “to document how we use those formats in a clear simple manner.” This is where the phrase “open standards formats” really ends up meaning open meta-data standard formats like XML.

IT’S NOT ABOUT FORMAT, IT’S ABOUT CONNECTIONS

In other words, your “data” is going to be portable – which I interpret to mean usable - only if there already exists an established – either by committee, by agency, or de facto – standard in which it can be stored, transferred, and interpreted. If I export a presentation from Google Docs I expect that it will be readable by Microsoft Office and OpenOffice and any other number of applications capable of importing that format. But if it isn’t in something at least akin to a standardized format it’s going to take a lot of translation work on the part of cloud application providers to import that data and make it usable for the user, if it even can. There’s bound to be data loss as not every piece of data will translate exactly to another piece of data in a similar but still very different internally application.

Take Twitter and Plurk. You remember Plurk, right? Okay, never mind. Take Facebook and MySpace. Two completely different systems accomplishing essentially the same thing. Both have comparable functionality and features, but are almost certainly designed and implemented using completely different methodologies and use different internal representations to link together all the posts, photos, friends, etc… together.

Taking all that data – the representation of your friends, followers, posts, messages, etc… – out of one of those applications may be simple, but the way in which MySpace developers will describe it using “open standards formats” is likely to be completely different than the way in which Facebook developers will describe it using those same “open standards formats”. That means Facebook has to develop a way to import and translate data from MySpace, and vice-versa. And it won’t be a simple process because some of the internal linkage between you and your “friends” is going to necessarily be lost.

Look at it this way, there is only one “Lori MacVittie” on Facebook. Really. So if “Lori MacVittie” is your friend on MySpace and on Facebook, the mapping between the two might be pretty easy. But there are 57 “John Smiths” on Facebook. So which John Smith is the same on MySpace and Facebook? Applications internally use unique identifiers to distinguish between users because of this problem, and often use e-mail addresses to further delineate when it’s not obvious. But what if I signed up for MySpace using a different e-mail account than I did Facebook?

And that’s just relationships, we’re not even going to dig into how to translate posts/notes/messages/tags/descriptions from one application to another and maintain integrity. Until we have that much we won’t even discuss how to translate privacy policies and settings so that my settings in Facebook stay the same when I move to “insert new social networking fad here”.

WHAT ABOUT THE OTHER APPS?

It’s easy to export documents and photos and even e-mail, but what about “my maps”? I spent several long years working in GIS and manipulating map data and let me tell you there is very little “standard” about it. Very little. What about my Waves? What about the applications I custom developed with my own special data? And that’s just Google. What about the plethora of other applications consumers are using to store data that don’t have a recognized “standard” schema? What about all the applications yet to be developed that are new and exciting and certainly don’t have anything resembling a standardized data schema?

That’s really what’s eating at me: exporting data in an “open standards format” is all well and good and it’s certainly better than not allowing me to retrieve it, but unless there’s a way to import that data into another application – and maintain its internal and external integrity – then simply freeing the data is not really worthy of all this applause.

It’s like being the only vendor to implement a new networking standard. Until interoperability with another product implementing the same standards is proven, no one really gets all that excited about it.

Related blogs & articles:

• Google's Data Liberation Front
• “Open” means more than just an API…Google’s Data Liberation Project Ponies Up
• Cloud Computing: Will data integration be its Achilles Heel?
• Duty Calls: Data Portability in The Cloud is an Application Integration Problem, Not a Cloud Problem
• The Cloud Metastructure Hubub
• Informatica: Data Integration in (and for) the cloud
• Infrastructure Integration: Metadata versus API