Wednesday, June 27, 2007

An accidental path to VRM.

Doc Searls is trying his best to come up with a coherent vision for VRM. He seems to be taking the straight on approach that works pretty good for lots of things of limited scope, such as Email, sending a file, TCP, etc.

VRM is such a nebulous concept right now that the scope is essentially infinite. This results in a "boil the ocean" view of things... which just doesn't work in the real world. I'm working on a completely different problem, but I think it might accidentally solve Doc's problem along the way.

Here's the general flow that VRM seems to take:
  • Somewhere, on a web page, X is described.
  • I tell my computer that I'd like to purchase X
  • The computer generates a file which specifies exactly my interest in X and puts it where vendors can see it
  • Vendors read the file, and the machines begin to negotiate
  • I pick the best choice, and approve the transaction.
  • I get X

My accidental path to VRM...

I'm interested in an ideological quest, to get what I call "markup" included in the web. My religious difference is that real markup on ... um... paper, for example... doesn't have to be done all at once. It can be layered... post facto. HTML just doesn't do it. Anyone who says otherwise is itching for a fight... ;-)

One of the ideas that you need in order to make real markup work is the ability to add content in a layer on top of an existing document. The word transclusion gets tossed in here... but it's got a lot of baggage associated with it. The basic requirement is to be able to say

this document is to be a layer on top of original_document_url
If you can do that, you can then do a lot of very powerful and new things with the web. The glue to hold it all together is a new set of places to store all of this new markup. It's fairly obvious to me that it wouldn't go anywhere on the original server for a number of reasons. It would probably get stored in a local repository, and then shared out to a community server somewhere to enable others to discover and read it. This need for a new repository of data is another common point of interest to the VRM problem. You're looking to add new data to something in a silo... you have to have a different silo to put it in though.

Making this new data discoverable and useful is a matter of aggregating, sorting, etc... it's a new Goggle class opportunity waiting to be solved.

The final link is that I'm interested in adding more than just text on top of pages, I want to be able to include metadata... and the VRM data would be a small easy to fit subset of that.

I hope this is coherent enough to make some sense to the rest of you. I welcome all discussion.


No comments: