Information Durability

[Bill French]

Lately I've been pondering business blog content durability - I think I'll rank #1 for this term soon because no one seems to care if their blog content is durable. ;-) But they should; it's an IT subject that few IT people seem to spend much time pondering.

I became concerned about content durability when I noticed how some business blogs are aging. This post elucidates the nature of testing and managing technical content quality (i.e., broken links, missing images, failure to tag, etc.). Tools that test for these problems have been around almost as long as the Internet, but few have been tuned to consider the business requirements of a business blogsite. I've previously covered the blog content quality subject in too much detail I suspect.

Content (or information) durability is about change - things are guaranteed to change; API's, XML standards (we have so many "standards" to choose from [wink]), and then there's the rendering platform. Chances are pretty good that almost every piece of information generated today will one day find itself being rendered by a different application than the one that initially captured it.

This wasn't true 10 years ago; applications were like data roach motels, but no longer do they make claim as the sole purveyors of information display. For example, content may find its way into Twitter, then over to Yahoo! Pipes, and then into Dapper, and on to a MyST Blogsite where it is then picked up by Google, rendered in a search feed, and fed back into a search mashup back on Pipes. Um yeah... information is like water droplets - it's in the sky, floating in clouds, falling on mountains, running down waterfalls, pooling in lakes, and sometimes it's being mixed with pollutants (another [wink]).

Anyway, you get my drift - durability. How do you create, store, and manage content that's durable?

[Bill French]

Thanks Arthur - these are mind numbing (er, I mean opening). ;-)

[Arthur Brock]

Oh yeah... a couple links xdi.org will give you more information than you want about the standards they've been working on. I think XRI draft 10 just made it through the community review process.

Also you should be able to reach me via my i-name for the next 50 years (then I'll have to renew it) at public.xdi.org/=artbrock.

[Arthur Brock]

I think part of what the problem you're pointing to has to do with the awkward transition from from the current document web to a more atomic data web.

Most people don't really think about it, but most of our protocols are for requesting and receiving documents: email messages, web pages, xml documents, etc. However, the information we seek is far more granular than the documents that contain it and we don't generally have good means for requesting the granules we want.

So Google indexes pages and tries to parse out content. Addresses and phone numbers get mapped and jammed into directories, but these documents continually become outdated. They are often a static snapshot in time and not connected to the underlying information source which is would be or could be kept up to date.

There are some folks doing some very interesting work in this domain. In particular the work on XRI/XDI standards and their associated identity project i-names. I think they've really got a solid technical approach to addressing this issue. However, there's a paucity of tools and modules to implement their standards and they're still pretty far away from elegant and friendly interfaces.

But think of it this way: What if you owned all your identity information and when you sign up for a site like this one, instead of giving another copy of information that will become outdated (email addy, phone, skypeID, bio, photo, etc.) you gave the site a handle to your source profile. Then from your end you can manage the handles (via link contracts in the XDI parlance). You can say NING has access these parts of my identity, MySpace has access to these, Facebook these others, my employer has these others, etc. and you can yank back the permissions whenever you want to because YOU own YOUR information.

If we took this approach for identities, links and other referenceable information via the data web, it wouldn't matter if you changed your domain name, my link could be updated as long as the content is still published.

A slightly deeper technical description of what they're doing... In the case of identities for example, they have i-names and i-numbers. You can loosely think of it like domain names and IP addresses. One piece of data can be pointed to via multiple names, or those names in the address space can change over time, but if I captured the i-number originally, I can be sure to point the actual data for as long as it is available.

This doesn't address the whole issue of what you're talking about Bill, but it represents a paradigm shift that I believe we're moving toward which could solve the lion's share of the problems with data durability. However, whenever you publish a disconnected snapshot, it will still become outdated. But some time in the not too distant future, we'll probably learn to ignore those sources of information as inherently apocraphyl and want to connect to the real deal via its eXtensible Data Identifier (XDI).

-art