Let Your Calendar Help Make Your Events More Successful

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:

1. An evangelistic pitch for the use of structured data for calendaring.

In Jon’s own words, more or less, “The elmcity project invites everyone who publishes community calendar events to: a) Realize that event data published in a structured format, unlike data published as HTML or PDF, can be routed through pub/sub syndication networks; b) Make public calendars available in the appropriate structured format: iCalendar (RFC 5545), the venerable Internet standard supported by all major calendar applications and services; c) Recognize that iCalendar is the RSS of calendars. It can enable a calendar-sphere in which, as in the blogosphere, everyone can publish their own feeds and also subscribe to feeds from other people or from network services; and d) Help build the data web by owning the parts of it for which we ourselves are the authoritative sources.”

Short of throwing in a reference to the “xCal”, the XML representation of iCalendar I mentioned earlier, and discussing crafting content for public events calendaring, I couldn’t have said it better myself.

2. An argument for making “Computational Thinking” the 4th ‘R”, in addition to “reading, writing, and arithmetic”, the canonical 3 R’s. “Computation Thinking”, which I had not previously heard of, is the work originally of Jeanette Wing (http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing06.pdf), a computer science professor at Carnegie Mellon University.

3. And, a Q&A session, which was perhaps the most interesting and revealing part of the webcast.

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/pubdocs/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