Comments on: Where Should The Data Reside?

By: anon

anon — Sat, 30 May 2009 07:51:50 +0000

can you kill the gravatar on that last post? i wrote it on a cookie-less comp, but appreantly it follows ip’s or something…it’s not good writing

…or kill the whole post?

thanks.

By: anon

anon — Sat, 30 May 2009 07:48:52 +0000

Couple disparate thoughts (it’s late so I’m a bit loopy):
–Google’s Wave will make this…is it worse? or better? However you look at it…I THINK they’ve got tools to embed Waves into your blog, his blog, her blog, everyone’s blog can have Allens Wave…
–the general motive of these re-re-et-al-re-publishers is to get google ad cash. They dont know google’s already filtering them out and/or they are a dime-a-dozen (search for some freeware and you’ll find hundreds of sites with same content – its the same idea with these blog/tweat re-publishers)..so they get lost in the crowd. Sure Mahalo (etc) has a bigger footprint, but it doesn’t matter…only sources matter (SEO) long term.
–@epc – good post…also, no way to FORCE an update on a remote site. And, no way to FORCE proper implementation of a protocol (say, if the protocol includes methods to force updates). eg. I did an email gateway years ago following the exact protocol. In the wild, it needed massive modding to accommodate everyone’s goofy/broken protocol implementations (even big names like IBM/Novell/MS/etc)
–Twitter to FF to FB to X then Y then Z and back to Twitter…infinite loop? Sweeeet…
–We got one post on another blog and saw it copied – exact copies – on hundreds of sites. Didn’t do anything – 99.99% of traffic came from original source (see above: re-publishers get few hits – I know someone’s going to argue this point…”I made $10 in one month…!!!”, big deal.).
–once its on the inets and google has it, you’re hosed. cat’s out of bag
–this reflects in the so called “Real Time” web (a misnomer). It’s only real-time as fast as the consumers are designed to re-consume…and as fast as the publishers can push. And as correct as consumers care to make it correct. Only the source is “real time” (even then, not really).
–”My take is that it’s fine to display content from other social services but it should be a display only — not/never a store and retain.” In theory I agree that’s how it should work. But it goes back to caring – by BOTH parties. If the publisher doesn’t care to display the data in a format people want (see: Twitter), a second party can come and suck it all into their system to format and re-display how users want to see it (see: Summize). And, if the “real time” publisher crashes, they don’t want to be pulled down too if their data is a mixture.
–you mention “data portability”. Is this about “data portability”? Isn’t “data portability” moving your private/semi-private account data from one site to another? Off topic, yeah, “data portability” is scary. Ever delve into FB Connect? Wow. Watch out what you wish for.

By: Allen Stern

Allen Stern — Sat, 30 May 2009 03:18:29 +0000

thanks for the great reply epc!

By: epc

epc — Sat, 30 May 2009 02:43:54 +0000

There was some great discussion about this at the recent “Glue” conference but no clearcut answers.

At a technical lever there’s a couple of problems: it’s trivial to syndicate the data, but non-trivial to synchronize actions on the data. If the feed is an Atom feed there’s a notion of stubs to reflect that a given bit of content has been unpublished, but this concept doesn’t exist in RSS which is what most sites use for data exchange.

There’s also no notion of what I’m going to call “contractual use of data”. There’s no way to obligate a subscribing party to either update a given element of data (maybe I published something in error and I want to push out the correction) or remove it (for whatever reason).

An author/publisher I know had a hell of a time getting bad data out of “the system” for a book he wrote. Initially (years ago) he’d talked to O’Reilly about getting it published. For whatever reason that didn’t go through. For reasons even O’Reilly admits were in error, the book appeared in a database update of upcoming titles. For the next several years the title showed up as an O’Reilly title complete with erroneous ISBN even though the author and O’Reilly quickly cleaned up the original bad data source. It flowed out to Amazon, then other sites and even to this day resurfaces years later.

The problem with establishing some sort of contractual obligation on data flow is …isn’t that DRM? And it is in a way I guess, but not in the sense of preventing copies or use but in requiring some sense of fidelity to the original data.

Atom tried to achieve a first cut at this both with the stub idea for deletions as well as the requirement of a unique identifier for each chunk of content — the idea being that even if you republish my blog post from my personal site over here on CN, the original id is maintained, but in practice no one does this and the tools don’t really support or enforce it.