Posted December 9, 2010

Earlier this week, I viewed (more listened, really) to a webcast from Harvard’s Berkman Center for Internet & Society (http://cyber.law.harvard.edu/events/luncheon/2010/12/udell), “Rethinking the community calendar: A case study in learning and teaching Fourth R principles”, by Jon Udell. Jon is presently a Microsoft “senior technical evangelist”, but he has also been a calendaring activist for some time through his elmcity project (http://blog.jonudell.net/elmcity-project-faq/). I have been reading Jon Udell since his days as a columnist for Infoworld, long before he interviewed
(http://itc.conversationsnetwork.org/shows/detail4176.html) CalConnect’s Mike Douglass and Steven Lees in 2009 about their work on the XML representation of iCalendar, now in draft 7 (http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-07) .

The webcast, like Caesar’s Gaul, was divided into three parts:

Those physically present at the presentation at Harvard posed the questions. Although I am not sure of the backgrounds of the questioners, they were clearly well educated, and reasonably tech savvy.

The questions, many of which were really statements, can be distilled (hopefully not unfairly) to, “Why do we need to know about calendaring formats or representations when we can simply have computers and/or œthe network” do this for us? They drew analogies to “modern conveniences” which we all own and operate successfully without knowing the science or implementation details behind them.

To me, this was reminiscent of the omniscient computers of Hollywood in their movie and television productions of the 1960 s, 70’s and 80 s, and, more recently, of IBM’s Watson project (http://www.nytimes.com/2010/06/20/magazine/20Computer-t.html?_r=1&hpw and http://www.research.ibm.com/deepqa/) which will pit hundreds and IBM’s best and brightest, along with a cluster of IBM’s biggest and fastest computers, against (most likely) Ken Jennings, a former software engineer who holds the record for most consecutive wins on the Jeopardy game show (http://en.wikipedia.org/wiki/Jeopardy!).

In some respects, what the Berkman attendees are looking for is some of what the semantic web promises to provide, albeit without the metadata and other infrastructure the semantic web currently requires. In all fairness, this is also what some of the large calendar aggregation services presently provide, albeit with a lot of human effort rather than automatically.

My own experience, overseeing development of an open source calendaring system, and providing public events calendaring for my university, is also instructive, albeit perhaps more mundane.

Along with events entered directly in to my university’s public events calendaring system, we wrote programs to “harvest” event data, which was not in iCalendar format, from the web site of one of our important departments. They subsequently outsourced the web site, and the event data was now in a form which required more time and effort to harvest than we could devote to the project, unlike the large event aggregation companies I alluded to previously. The new web site subsequently made the event data available as a vCalendar feed, which had many of the problems outlined in CalConnect’s “The Benefits of iCalendar for the Mobile Industry” (http://calconnect.org/publications/CD0611%20The%20Benefits%20of%20iCalendar%20for%20the%20Mobile%20Industry.pdf), most notably the lack of unique event ID’s , making it impossible for us to distinguish updated events from new events. To the vendor’s credit, they allowed us to engage in a dialog about their calendaring implementation, and they now provide iCalendar downloads and subscriptions, with unique event ID s. However, the event times are all expressed in UTC, not with proper timezones. Although the majority of our events are in the same timezone as the university itself, not all events are. Hence, we cannot automatically present the event time as the local time for those interested in attending or participating in person. In the UTC representation, some evening events appear to extend into the next day, which is almost never the case. Additionally, referring back to “crafting content for public events calendaring”, most of our location data is expressed in a very local context (“Library Conference Room”, etc), which does not work in the elmcity context of aggregated calendar subscriptions. Importing our events into Google Calendar, which attempts to automatically represent event locations in Google Maps, was illuminating. Google did not recognize the unqualified acronym of one of the most important on-campus venues, displaying it as a location 3000+ miles away in France.

It is likely the case that in the not too distant future, the same computer systems that will defeat human competitors in TV game shows will also be able to correctly recognize and process all unstructured event data. Unfortunately, that day is not with us yet. Interoperable calendar formats, such as iCalendar (and XCalendar), and interoperable calendar protocols (CalDAV, iSchedule, etc) are the best paths to interoperable calendaring, and ultimately, more successful events, which, after all, is really our goal.

Gary Schwartz
President, The Calendaring and Scheduling Consortium