Cluster

diagram showing calendar syndication and republished aggregated calendarSo. Having done some research: a number of sites offer calendar hosting and search. Well and good. But obviously not enough to get people very excited: these sites are mostly fairly low-key, even though they offer some fairly high-value data (calendars for sports rosters, national holidays and so on), that in a world truly turned-on to the power of calendar pub/sub, you would reasonably expect to find not tucked away on a hosting site, but regularly updated on the websites of the related organisations, teams or governments. There’s a real gap between potential and perceived value.

What’s missing? Or a better question: what’s needed to push this into broader consciousness? Two inter-related aspects: passion and personality. People care about calendars because they care about stuff which happens: bands go on tour, teams compete in championships. People will pick up on technology to the extent that the people who are doing the stuff that people care about (let’s generalise them as actors) pick up on it. we don’t need more sites hosting random collections of calendars, we need the people who do stuff hosting their own, so the people who are passionate about what they are doing (lets call them the fans) can keep closer in touch, more easily.

But it’s rare than fandom is limited to a single actor — most fans care about related clusters of actors and what they’re up to. Currently fans who want to track a number of actors’ calendars use client-side aggregation/layering in desktop software like iCal, giving them their own personally aggregated ‘calendar-of-me’, reflecting their varied passions and predilictions.

And there it currently stops.

As if we had never had IMDB, playlists or Amazon lists, or any of the other network-based, edge-fed collaborative filtration systems. What’s missing: internet-based publication of those personally-aggregated clusters of actors and events back online, so we can all benefit from the incremental value added at the edge by people who care about stuff, and aggregated back into the network (the purple arrow in the above diagram). With that feedback in place, we could start building systems that harvest value from network characteristics and patterns: popularity, clustering, geospecificity. The (small) benefit that each edge user accrues from their own desktop aggregation would be no longer be lost out at the edge, but instead become part of (yet another) network of live networks (like all the others with which we are now familiar: CDDB (as was), page ranking, LiveFM, mp3 playlist search etc.). And I think aggregation does add value for calendar systems. Amongst other network effects, it’s easy to see how preferrential aggregation would quickly give rise to ‘instant fame’ for fans whose calendars were really useful to others: imagine city-wide gig guides for specifc genres of music. Or the stickiness of such guides if sponsored by famous DJs or music critics. There’s something to this. More thinking to do

Have been playing with interfaces. Cluster now includes a daily calendar (see right) of what‘s on on the London music scene (that I’m interested in — big caveat!). This is generated by a perl script from PHPiCalendar RSS feed. At the moment this is from a single feed, but there is no reason this itself could not be generated from syndicated calendars (as and when this catches on).

Every day, I receive emails, newsletters and catalogues informing me about some small subset of the thousands of potentially interesting things on in London. If I’m really paying attention in the moment, I might actually get around to typing some of them into my ipaq and maybe even get around to booking. More usually, though, the moment that I see the information is a moment when my attention is mostly occupied with something else: looking though email for an important messsage from a client, or opening letters in the hope of finding a long-chased invoice. Most event invitations simply get trashed because they simply arrive at the wrong time for me to pay attention to them.

Sound familiar? This is much the same problem as we faced catching up with news and opinions pre-RSS syndication/aggregation. Would that there were a similar tool to take care of our diaries for us.

But of course there is: RFC2445/iCal is a nice, simple(ish) specification for internet-friendly (and more importantly aggregation-friendly) scheduling. With RFC2445-compliant client software, it is straightforward to publish a calendar on the internet, and equally straightforward to subscribe to multiple calendars and aggregate them as you wish. So, for example, I could have my own personally-aggregated diary comprised of the iCal diaries published by all my favouriite venues and organisations: no more scanning through endless newsletters to see what’s on and when.

Apple even provide, as part of their .Mac hosting service, easy online publication of personal or organisational calendars straight from their iCal application.

So why hasn’t calendar syndication really caught on?

I’m guessing that it simply hasn’t yet reached tipping point. Apple may be ahead of the game, but they’ve not really lit the fire of hype under the whole idea, and robust iCal calendar clients for other platforms have been slow in development. I’m guessing that all of that will change soon: Mozilla’s Sunbird is coming along nicely. And there are webby RFC2445 clients such as phpiCalendar which do a fine job of rendering aggregated diaries online. Even better, phpiCalendar also generates RSS feeds based on daily/weekly/monthly schedules, all ready for aggregation via any RSS aggregator/ticker. Surely the calendar revolution must be almost upon us?

Or at least: there must be a first mover business opportunity in there somewhere. I think Apple have missed out: I like their .Mac personal hosting service (which I think is actually a bit bigger and slightly more clever than it initially appears (more later)), but they just aren’t pushing this hard enough. In any case, calendar syndication seems, to me, an obvious adjunct to hosted blogging. Time to get on the phone and see who is interested…

I guess I should be putting my money where my mouse is: my own calendar (mostly London-based music and art), hand-aggregated from various sources, can be subscribed to using an iCal-compatible client using this link. Or, there’s this web view, with daily and weekly RSS feeds. Have fun. Of course, in a world of federated calendars, I wouldn’t have to prepare this by hand: I could just point you at some OPML-ish XML with my favourite diary sources wrapped within.

I’ve been looking at the practical details of open calendar services and schedule aggregation/syndication. Seems, at the moment, that there are sufficient tools to make calendar syndication possible, and a gentle bubbling-under of interest in the idea. Personally, I’m of the opinion (a more reflective post on why to follow shortly) that schedule aggregation might well be the Next Big Hyped Thing, so I’ve wanted to check out the state-of-the art. So far, iCal and SunBird seem the best mainstream tools for creation of standards-based, internet-accessible calendar information (over the web via webDAV). The best tool for web-based publication (of locally-stored iCal stores) seems (so far) to be PHPicalendar, which even automagically generates RSS feeds (daily/weekly/monthly up-coming events). Nice. More on this soon.