There is an ongoing discussion on the validity of the "Web 2.0" moniker, started by Tim Bray, rejoined by Tim O'Reilly, and refined by Sam Ruby and many others. The whole discussion is fascinating not only for technical points, but for the psychological aspects. There is no hard and fast definition of "Web 2.0" and the nature of that nebulous concept allows it act like a technologist's roschach test.
It's like a rorschach test
It's like a rorschach test, which let's everyone pour their own thoughts and ideas into it, forming it to how they see the world. What shouldn't be suprising is that I see the world diffently from most people. To get some perspective let's look at Sam's categorization of the three phases of the web to date:
- Web is exemplified by static home pages, published in broadcast mode. Many weblogs today continue to operate in this fashion.
- Web is exemplified by e-commerce shopping carts, enabling two way interaction between business and consumers. Comments and Trackbacks are in this category.
- Web is characterized by action-at-a-distance interactions and ad hoc integration. By my putting a link here, your page rank is changed there. A book I purchase today affects Amazon's recommendations tomorrow.
The One-Way Web
My view differs slightly. At first there was a mostly one-way web. If the communication was two-way it was strictly between one client and one server.
Here is a picture of Web. The only interaction is through web forms. This is useful for dropping comments on a site, or buying a book.
The One and a Half-Way Web
The next stage is more interactive, with trackbacks, pingback, and personal publishing. This diagram is also missing an arrow, one that goes from Server1 to a news aggregator. That arrow represents RSS and syndication.
Note that all the arrows represent different formats and sometimes even different protocols. Web pages are server over HTTP, but may be uploaded to a server via FTP. Feeds are one of the many flavors of RSS. The publishing method could just as well have been WebDAV or the Blogger API. Each part of the infrastructure is different. It's like living in an old house where the plumbing is a mix of copper, steel and PVC -- every transition requires a custom fitting.
The Two-Way Web
This is where we're headed.
With the rise of Atom we can start to standardize some of that plumbing. Publication can take place via the Atom Publishing Protocol, which is just a way of pushing Atom Entries up to a server. In turn those Entries can be published as an Atom Feed. Trackbacks? Those are just Atom Entries pushed over HTTP too. Same thing for comments. Now we've got Atom Entries traveling from client to the server, from server to the client, even from server to server. It's an entire Atom Entry eco-system.
When blogging isn't blogging any more.
A Greasemonkey script that can publish Atom Entries.
Now we're talking real power. How about a script that blogs books to your book blog everytime you visit Amazon? Or how about one that finds links to FOAF files on web pages your browsing and then blogs that information to your people blog? How about mining microformat information, a Greasemonkey script could find all the hCalendar information in all the web pages you visit, or cull them from entries on Bloglines, and publish them to your calendar blog. The possibilities are endless.
How do you know a technology has matured? When it becomes invisible. Look at all the blogging that's taking place in the above scenarios. Look at how much of it could be automatic, easy, almost invisible.
Now let's loop back to something I wrote two and a half years ago, Stigmergy and the World-Wide Web. Stigmergy, a term coined by French biologist Pierre-Paul Grasse is 'interaction through the environment'. In that essay I outlined all the ways in which the web acted like a stigmeric communication system for people. In the Atom Powered Web 2.0, that vision doesn't change, the same principles apply, it's just that with standard plumbing the trails are laid down even faster.
If you think I'm pushing the envelope with what can be done with Atom and the APP I'll again point to Adam Bosworth's "Database Requirements in the Age of Scalable Services" [via lesscode.org].