Ok, this is getting a little, err, funny isn't it? All kidding aside. All these sworn enemies (Facebook, Plaxo, LinkedIn et. al) getting together at DataPortability.org to smoke the peace pipe and, err... share. Supposedly they want to allow people to "own" their data and to move it between platforms. SUUUURRRREEE!
But OK lets just play this out for a second and actually take it seriously. Don't get me wrong, I am totally down with the data porters and stuff. But it just seems to me that the idea really shouldn't be about *porting* data but accessing data, *in place*.
Because what I really want to do is ask for stuff and get it, and not worry so much about where it came from. For example, I want to send something to all my high school friends, or all my friends in the New York area - regardless of what "social network" they are on. Yes, I should be able to port my contacts into Outlook. But it would be so much better if Outlook was just a *window* into my broad universe of data, not just some other silo that I can use to store *yet another* copy. Oh, and you semantic webtards, I don't want to hear a freakin' comment about how this done in freakin' RDF. It will never happen. You know why? no one freakin' gets all that semantic web RDF/OWL/SPARQL gobbledygook!
So, unfortunately, I suspect nothing really cool will come of all of this, and that where things are really heading is some giant import/export engine in the sky. And to me, that is just so Milli Vanilli. And yeah, in case you're too young to remember, they sucked.
2 comments:
What's not going to happen is to have any service provider trust another 3rd party provider for storing "their" data. I wouldn't, if I was running such a service. If they go down, you go down? No thanks. And how can you hope to perform basic back-office tasks like trend analysis, data mining and the like without the data being stored in a local database? Provider local storage is just a reality we're going to have to live with for the next few years.
Now if you were to argue for some notion of "cloud" storage of your personal data, and any service provider that you used could make a local copy of that cloud data for their own processing purposes, I would agree that scheme could be made to work. But then the very next step would be to define the cloud storage format "esperanto", so that multiple providers could use that data seamlessly, right? And isn't that pretty much exactly what this effort is, or heading toward?
Rick
"What's not going to happen is to have any service provider trust another 3rd party provider for storing "their" data. I wouldn't, if I was running such a service."
What people are not comfortable with today they get comfortable with tomorrow. Amazon has proven that with their web services. Its all a benefits analysis.
But in any case, thought that is one way to do it, another is where we provide gateways to data that can be fronted by other applications. This is indeed what RDF & SPARQL are about. But they are too complicated so no one will do it. The idea is right but the design is to academic. HTML succeeded because it was simple. Just like SGML, its older cousin, failed because it was too complex.
"Now if you were to argue for some notion of "cloud" storage of your personal data, and any service provider that you used could make a local copy of that cloud data for their own processing purposes, I would agree that scheme could be made to work."
I think the minute you start talking about *copying* data, the end is near. Copying data does not scale.
"But then the very next step would be to define the cloud storage format "esperanto", so that multiple providers could use that data seamlessly, right?"
Yes!!!! but the problem is that the efforts so far are primarily about file formats like microformats, whereas what we need are protocols. caldav is a great start for calendars for example, but there is no server based protocol for contacts. We have vCard, but that is static.
Post a Comment