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.

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.