Registration has opened for CalConnect XX at UC Berkeley, February 7-11 2011

Registration is now open for CalConnect XX, February 7-11, 2011, at the University of California, Berkeley, in Berkeley California. Please see http://www.calconnect.org/calconnect20.shtml for logistics and registration information for the Roundtable and for the Interoperability Test Events.

Note that we will be conducting both a regular Interoperability Test Event and a Mobile Calendaring Interoperability Test Event on February 7-9, 2011. More information about the regular IOP Test Event is at http://www.calconnect.org/iop1102.shtml. Information about the Mobile Calendaring IOP Test Event is at http://www.calconnect.org/miop1102.shtml.

The meeting venue will be in in Barrows Hall on the University of California, Berkeley, Campus. The logistics page includes a map of the area (including the location of the meeting venue and hotels).

The Conference Hotel will be the Shattuck Plaza Hotel in Berkeley. The hotel is within walking distance of the campus and the venue, and is 1/2 block from BART, the Bay Area Rapid Transit system, which serves both San Francisco International Airport and Oakland International Airport. CalConnect has a special discount on the lowest available rate for this event. .

Berkeley is served by the San Francisco, Oakland, and San Jose International Airports; public transportation via the BART metro system is available from San Francisco and Oakland as mentioned above. Information about the airports and available ground transportation is available on the logistics page.

We will be announcing additional and special sessions of interest as more material becomes available. At this time, while the general schedule is set, we cannot guarantee that the specific dates and times set on the logistics page for each TC will not change.

Organizations interested in CalConnect but not members are welcome to attend the Roundtable as observers. See http://www.calconnect.org/observer.shtml for more information.

Organizations are welcome to particiate in the Interoperability Test Events whether or not they are CalConnect members. Please note that the registration fee for the IOP Test Events covers both the regular and mobile calendaring events, which are held in parallel.

In calendaring, success means the right thing, the right way!

CalConnect, as you learn from our web site, http://www.calconnect.org, “is focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies. The Consortium’s mission is to promote general understanding of and provide mechanisms to allow interoperable calendaring and scheduling methodologies, tools and applications to enter the mainstream of computing.”

We encourage, promote, and provide assistance in doing the “right thing” with respect to interoperable calendaring. Sometimes, however, doing the right thing is not quite enough – you need to do the right thing the “right way”. A recent example helps illustrate this point.

In the U.S., athletics are a big part of the collegiate experience, unlike most other parts of the world. Most of the biggest collegiate athletic programs now outsource their athletics web sites, even when the college’s other web sites are hosted locally. These athletic web sites are hosted by a handful of vendors specializing in this work. These web sites are designed to look like the most popular professional sports web sites, and depending upon your age, and your aesthetic sensibilities, you find these sites either energizing or enervating.

I work at a university that uses an outside vendor to host and manage our athletics site. Recently, to understand how our capabilities compared, I unscientifically surveyed the athletics schedules at top programs in basketball and football. I was looking for the ability to download an iCalendar (RFC 5545) format (.ics file) of the schedule, and/or subscribe to an iCalendar feed of the schedule, which amounts, more or less, to the same thing.

Not all web sites provided the schedule in iCalendar format, but for those that did, I assumed that I would have no trouble importing and displaying the schedules in other calendaring systems, desktop or “cloud”. Jon Udell, in his recent talk at Harvard’s Berkman Center for Internet & Society, reminded us 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.” Nonetheless, what I discovered surprised me.

I downloaded an iCalendar file (.ics) for a contest between a college in the western U.S. and a visiting team from the eastern U.S.. It was displayed on the web site of the visiting eastern team as starting at 8:00 PM, not the local California start time of 5:00 PM. However, because the events were represented in UTC, one of the 3 time formats defined and supported in RFC 5545, when imported into other calendaring systems (such as Google, Yahoo, Outlook, etc), the event was displayed as starting at 7:00 PM eastern, which was not the correct time at start time for the event or relative to the local time of the visiting team . This was because the iCalendar data was generated using an incorrect UTC date and time offset. This is an easy error to make as in those places which observe daylight saving time (DST), the UTC offset is not constant throughout the year. Since most events are specified as a local time in a particular timezone, it is far better to generate iCalendar data in that same way as that eliminates the possibility of errors such as the one illustrated here.

When I downloaded and imported an .ics file schedule of another university from their web site, produced by an even larger vendor, another problem emerged. The iCalendar file did not represent timezone information properly, which resulted in all the events being interpreted as “floating time”, another of the supported RFC 5545 time formats, although the intent, upon inspection of the .ics file was to be in ‘local time with timezone reference”, the third and most relevant time format in RFC 5545. Floating time (also referred to as local time), “represent(s) the same hour, minute, and second value regardless of which time zone is currently being observed”. Floating time might be appropriate, for example for a jogger, who religiously blocks out 6:00AM – 8:00 AM for her/his morning run every day, independent of where he/she may be, whether it is a weekend, holiday or anything else. However, this is not true for an athletic contest, which has a specified starting time in relation to a specific timezone. When I imported these events into other calendaring systems, they were the same local time everywhere, making them incorrect when displayed in calendaring systems almost everywhere.

In both cases, the format of the .ics was conforming enough to allow them to be imported without error into other calendaring systems. However, the semantics, of these .ics representations were not conforming to the event organizer’s intent – informing people when these events were to start. Date and time information needs to be stored as completely as possible with as few assumptions about the context as possible, for both internal consistency and interoperability across online calendaring systems. This means almost always representing event information in the RFC 5545 “Local time with timezone reference” format.

Calendaring standards and formats are just a means to an end – making our events more successful through stronger attendance, creating publicity for the event or sponsoring organization, or bringing distinction to the sponsoring organization. In order to achieve these objectives, we need to ensure that our meaning and intent are conveyed properly across calendaring system boundaries.

It is well worth your while to run through the exercise of exporting your public events, and importing them into the more widely used calendaring systems to ensure that you have, indeed, done the right thing the right way.

Gary Schwartz
President, The Calendaring and Scheduling Consortium

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