Scott McMullan: ehick

Google/Internet Archive, Meet Mr. Event

In the spirit of "tags are the new black," here's a vision for how event and calendar management should be handled by 2006:  Wouldn't it be grand if all events in the world, from a garage sale in Lexington to a tech conference in SF, could be automatically discovered (Google), stored in one central, public domain, web services accessible database (Internet Archive), where the events could then be categorized (Topix), community rated and recommended (Amazon/Netflix/Last.FM), personally tagged (Flickr/del.icio.us), and ultimately custom-fed (PubSub) directly to your calendar device of choice (Calconnect)?

Cool, where do I sign up? I Could have used this to promote our now defunct SF Web Services SIG, which was done "by hand," one site/email list at a time.  Not to mention the relative difficulty when you go searching for a good event in your area...(not to knock workit.com or craigslist.org -- thanks guys!)  But I want this uber event service now!

So past and current pains combined with threads followed, dots connected, and small wheels turned since last week's Berkeley Calendar Project post create this mashup event service vision.  Actually, people are talking about this vision in so many words.  Dr. Bob Glushko and Allison Bloodworth et al are leading part of the effort by trying to bring sanity and sharing to the 80+ event calendars of UC Berkeley.  Tantek Çelik and other folks working on hCalendar talk about using your web site as your API,

"...bloggers can discuss events in their blog(s) in such a way that spiders and other aggregators can retrieve such events, automatically convert them to iCalendar, and use them in any iCalendar application or service.",

Kevin Hughs at zLab writes,

"The potential for applications that make use of networked, time-driven information is huge. Today's portals have no concept of event personalization or collaboration. Today's applications have only the most basic concept of integrating with or subscribing to time-driven data. And there are no providers of horizontal event-based services. ... Software and the Internet has freed online music from its proprietary data and application jails, why not do the same with events? The traditional calendar interface deserves a overhaul.",

Marc Canter chimes in,

"I wonder if they wanna help put up shared XML servers of Events - scraped from throughout the web?",

the Calconnect.org folks proclaim,

"Our members’ intent is to enable calendaring and scheduling tools and applications to enter the mainstream of computing," said Dave Thewlis. "After email, the World Wide Web, and instant messaging, calendaring and scheduling capabilities are what business people and consumers will really care about.",

and many many others I have yet to discover [add more in comments].  Yes, A few people are already doing similar stuff, like upcoming.org, rsscalendar.com, openeventscom, whizspark.com, evdb.com(?), and most likely Google Labs (?) [any more?].  But for starters, from what I can glean these efforts rely on people coming and manually submitting events, rather than auto-discovery and aggregation via spidering --> problem of db critical mass.

So let's make one!  Let's combine something practical and "standards-based" (ie., iCalendar/XHTML) like hCalendar, but extend it with the rich UBL-inspired semantics of a Berkeley Event Model.  Now that everyone agrees, let's move one.  We need open source tools so event producers (even for my yard sale) can list their events on their blogs/web sites, like they already do, but also be sure to use valid markup.  (Note: people are motiviated to promote their events -- no prodding necessary)  Then we need an open source spider, a bunch of disks and some linux boxes, a REST API, open source recommendation and reputation/rating/tagging engines (eg., tweaked openscrobbler + ??/??/??), and some pub-sub and feed generators.  And to top it off, let's make the database and service usable by all (eg., some kind of creative commons), so we can unleash the creativity of the world to build custom interfaces via our web services API.  Easy stuff in these days of inspiration from  Amazon/Google/PayPal/eBay/SForce, open source, wikis, bugzilla, and PayPal donate buttons.  Right?

The law of ideas says that at least 6 (or is it 8?) people are either building or have already built this exact event service -- and I haven't found it yet.  Any pointers?  If not, anyone want to build this monster?

Calendar Federation and Syndication at UC Berkeley

Jon Udell and others are having a discussion about the sorry state of calendar sharing, both standards activities and clients/platforms (see also Ted Leung and previously Lisa Williams).  The particular discussion is centering around Mozilla and Chandler and how to use WebDAV/CalDAV as a transport for calendar sharing.  But at the end of his first post, Jon writes:

"I wish there were a middle ground between this model and the dedicated calendar server. Imagine a WebDAV implementation that could map collections not just to whole-file resources, but to XML elements within files. Given an XML flavor of the iCalendar format, you could achieve more finely-granular control over calendar data. But the same model would work for other applications using other XML formats. And you'd have the option of searching with XPath or XQuery, again leveraging infrastructure not bound to any application domain."

He summarizes nicely some of the goals of the Berkeley Campus-Wide Event Calendaring Project, headed up by Allison Bloodworth and others from Berkeley and the CDE.  The project was motivated by the fact that there are something like 75 different calendars at Berkeley, and there's no way to easily share events or create user-friendly views or feeds.  (BTW their work just won the best presentation/paper award at XML 2004 -- kudos!) 

So their focus is to apply Document Engineering techniques to create the XML data model that accomplishes Jon's wishes, and then apply model-based app techniques using XML/XSLT/XSD to create software and glueware to manipulate those events (eg., create calendars).  Borrowing from their XML 2004 presentation, they summarize their solution:

• A standard XML data model of an Event (Scott says: think UBL for events) http://dream.berkeley.edu/EventCalendar/Events.xsd
• A centralized repository of Event information
• A calendar management tool
• Manage events in the repository
• Customize a visually compelling, dynamic web-based calendar
• A design for a system architecture allowing XML feeds to and from the repository for calendars who choose to maintain their own website & repository

They have the XSD schemas and have some software built.  This is important related work if you're interested in calendar sharing and syndication -- check it out.

[UPDATE:] From Adam Rifkin's excellent Microformats post I found hCalendar:

"hCalendar is a 1:1 mapping of iCalendar to semantic XHTML. ...bloggers often discuss events on their blogs -- upcoming events, writeups of past events, etc. With just a tad bit of structure, bloggers can discuss events in their blog(s) in such a way that spiders and other aggregators can retrieve such events, automatically convert them to iCalendar, and use them in any iCalendar application or service."

This Microformat philosphy is pragmatic == I like!.

Browser-Based Application Architectures

Oliver Steele of Laszlo Systems recently posted a good history of various browser-based application architectures.  Most interesting is his definition of "client-side web applications" in contrast with Model 2 (or Model 2X) and other evolutions he calls Model3 and 4:

"In a client-side web application, a single web page (or its application equivalent) is downloaded.  This application can generate a sequence of views on the client.  Sometimes the client application requests a new dataset — typically in XML, or a protocol (RPC, SOAP) that is serialized to XML — but this dataset is read into the client application; it doesn’t replace it."

While a good definition and fine architecture, Oliver is making client-side web applications sound newer than they are.  Wasn't this the whole idea behind Java Applets?  Granted the first applets didn't have all the architectural pieces right (eg., port 80 issues and server architecture needed to be home grown), but many people who committed to applets in the late 90's ended up exactly as Oliver mentions.  At Inovie our entire TeamCenter product was a judicious mix of java applets (Swing -- gag!) and HTML, all done as HTTP over port 80.  For portions of the app that really benefited from a rich interface, a single applet was loaded, and as new views were requested, the applet communicated with the server to get new data. Great post, just adding some additional context.