The renovation of the upper floor of our house has taken most of my time the last few weeks, and that should explain why this blog hasn’t seen any updates since April 2. But most of the heavy work is behind us now, so I’ll have more time (and the inspiration, I hope) to post more frequently.
During my lunch break yesterday I read Dave Winers thoughts on the future of Twitter. I’m not exactly an expert on the subject of Twitter and the applications that have been, should be and could be built around it. But I find 140 characters of plain text frankly unattractive and hardly inviting, even for simple messaging. Dave’s proposal to have metadata attached to a tweet would help overcome at least a part of the current limitation, and make Twitter a much more powerful communication mechanism. Working with all kinds of content management systems and the unavoidability of metadata in them makes annotating a message, be it small or large, a very natural reflex for me.
I have written about Microformats in the past; they’re just metadata within a larger document like a web page (or part of a web page). I consider them to be a small step on the road to the Semantic Web. You could say that the Microformat approach is a top-down way to annotate small islands of data in a large document. Dave’s proposal is a bottom-up approach: take a complete “document” and add metadata to it. The effect is similar: information gets enriched and thus gains value – perhaps not necessarily for you, but perhaps for others, or for specific applications. Take my posts about the electricity production of our solar panels: wouldn’t it be good to be able to have a standardized way to indicate “monthly solar production in KWh” in a web page, to facilitate comparisons with other installations?
There are other forms of annotation in existence, although not many of them are in any sense popular: RDF, Topic Maps, and – of course – RSS (I consider Atom to be part of the RSS family). RSS can and does contain metadata, even if their scope is limited. If we want to keep a fighting chance to make all these tools compatible in some way, we’ll have to stay with XML as the underlying data format. Or at least with a format that is easily convertible to XML…
All in all, the objectives aren’t too difficult to understand nor too complex to implement: who’s going to build a server application that delivers what Dave would like to see? If I may add just a single requirement: remove the 140-character limit on the message?