Semantic Calendaring

For those who don't know, there are occasional discussions in the Internet industry concerning what is termed the "semantic Web". Essentially, a conception of technology standardized in such a way as to encode not just information, but meaning, so that computers can do the tedious work of organizing information, the Semantic Web is the holy grail of the Internet. Less "search" and more "find".

In a sense, the Semantic Web would do for researching information what robots like Aberystwyth University's ADAM are beginning to do for scientific research. ADAM, when supplied with a stock of yeast cultures, and without any human direction, formed hypotheses and performed experiments, identifying genes--some of which had been independently discovered by human scientist before, some of which had been unknown to carbon-based researchers before ADAM discovered them and its human colleagues verified the results.

Yet, despite all the talk about the Semantic Web, there's been very little, that I can see, by way of progress in realizing the vision. The biggest impediment, it seems, is that content providers simply aren't on board. Information is produced willy-nilly, in semantic isolation from similar stores of information elsewhere generated, with no thought as to the tedium that is likely to face human beings who must sort through and collate that information on their own.

A case in point is online event calendars. A data exchange standard for calendaring information, iCalendar, was first proposed in 1998, and yet a decade later, it is rare to find content providers that offer their event listings in iCalendar format.

Of those that do provide a way to work with their data, it is usually delivered as an RSS feed, often without even bothering to encode the event date in the admittedly ill-suited pubdate field. Most providers, however, simply provide some sort of list, formatted to look pretty on the screen, but with no consideration given to how a computer might encounter the same data. The year of an event may be found only as a section header, time zone information is almost never evident, and even meridiem notations seem to have no fixed abode, appearing sometimes after the start time, sometimes only after the end time, sometimes with leading spaces, sometimes scrunched up next to the numerals they modify.

More often than not, when an RSS feed is offered, it includes a raw unencoded dump of an event description written in some word processing program or other, producing invalid feeds that RSS readers and aggregators barf out or silently ignore.

It goes without saying, that absent a reliable source of calendaring content, calendaring application developers have not given much attention to developing even simple calendaring clients, let alone smarter semantic agents. Microsoft Outlook only obtained the ability to subscribe to events calendars with its "2007" product. Google Calendar still doesn't know how to handle query driven iCalendar data--stripping away everything in the query string--and Google Sync for the Blackberry fails to work at all for a large crop of users, with no apparent explanation or effort to identify the issue. Desktop based sychronization products are little more robust.

Meanwhile, mashup tools are consistently parochial: so far as Yahoo Pipes is concerned, all times are Pacific Standard (or Pacific Daylight depending on the season).

The result being that Internet calendars remain isolated, each in their individual silos. Want to know what's going on in your neighborhood this weekend? The local newspaper events calendar, Time Out digest, Learning Annex kiosk-zines are now joined by such players as Meetup.com, Upcoming.org, Happenings.com, and Eventful.com, plus a host of calendars produced in paper and online form by libraries, museums, music venues, universities, chambers of commerce, community centers, and various local and regional governments and government offices: none a comprehensive source.

Likewise, for those publicizing events, increasingly fractured channels of distribution means that most of the people who might want to know about your event will never find it. It is simply too much work to submit the same calendar entry to more than two or three channels.

We really could do better. Heck, before and after the first Internet bubble, I consulted with clients who were seeking to distribute, deliver and/or produce events calendars to maximize their reach and provide event-goers with as much ease as possible. The technology, the infrastructure, the cultural standards, just weren't there. They still aren't.

Those of us who are serious about calendaring, pour energy into hacking together solutions. Yahoo Pipes, Dapper, Popfly, CGI and PHP scripting, Web services, desktop synchronization agents, and handheld apps are strung together in amalgamations of mashups, rickety Rube Goldberg contraptions spanning across chasms of virtual space, from server to server, platform to platform.

The nassauwalks.org calendar of walking events on Long Island is an example of just such a bubble-gum-and-spit calendaring aggregator, pulling together information from sources that simply were not designed to be brought together. Indeed, every so often I find myself devoting untold hours to cobbling solutions from ill-fitting parts, all the while wondering what it would take to actually get content providers and distributors together to produce a semantic framework, to realize a Web 3.0 architecture. Then I run across yet another Web 2.0 service that is poorly implemented, unnecessarily obscured, or just plain broken, and come back to the reality of the situation: the culture just isn't there.

This rant follows on some tens of hours of frustration trying to find a way to get various New York area event calendars onto my Blackberry and into Outlook. I've finally got a workable solution, although not perfect. One data source I had planned to incorporate is--unfortunately--simply broken, and I'm waiting to hear back from the provider as to whether they're going to fix it or I have to write a CGI script to munge the RSS myself. Another data process that I was fleshing out is currently locked in a Yahoo Pipe that, while it runs without complaint, is mysteriously no longer editable--with no explanation thus far from the Pipes administrators.

That all said, after putting so much work into this project, I want to share, and so I provide links to the resultant iCalendar services, however kludgy, here.

New School Events: http://www.dapper.net/services/New_School_Events

NYU Public Events: http://www.dapper.net/services/NYU_Public_Events

NYU Alumni Events (NYC):
http://www.dapper.net/services/NYU_Alumni_Events_NYC

NYPL Adult Events:
http://www.dapper.net/services/NYPL_Adult_Events