Revisiting FuseCal and Upcoming

As calendar curators begin bringing the elmcity project to life in their communities, they’re broadening my horizons. Last year, for example, in the comments on this entry, I learned about FuseCal, a calendar-publishing service that can extract structured calendar information from semi-structured web pages. I’ve been using FuseCal ever since, but in my community I’ve only found one otherwise-inaccessible calendar that it can successfully parse. Curators in other communities, however, are finding more. The Baltimore list includes a handful of them, and so does the Huntington, WV list.

In that comment thread, I tweaked FuseCal’s product manager Matt Gillooly when I said that a service based on HTML screenscraping shouldn’t need to exist. His reply was spot on:

I agree that, ideally, FuseCal wouldn’t have to exist — in the same way that, ideally, hospitals and prisons wouldn’t have to exist. :-)

Seriously, though, I think you need to provide a lot of incentive in order to get people to change the way they behave. It’s much easier to sell a Tylenol than a vitamin.

Matt’s right, of course. My goal for this project is to bootstrap networks of calendar feeds in communities. What matters is lighting up feeds, much more than how they get lit. So it’s great to see FuseCal lighting up feeds in Baltimore and Huntington.

Another service that has seen limited use in my own community, but will be more important elsewhere, is Upcoming. It’s ironic because back in 2005, when I first started thinking about this stuff, Upcoming was the model for what I hoped would emerge in Keene. I walked around town that spring, took photos of event posters, noticed how little of that information was available online, and wondered what it would take to fix that. I’d been using Upcoming myself, but hadn’t had much success getting anyone else involved.

In a blog entry I mused about ways to improve the service. One of my suggestions was to provide an API, and Upcoming’s founder Andy Baio heard and responded.

Four years later there still aren’t many Upcoming events for Keene. But as other communities come online, I’m finding that Upcoming is more popular there. So I’ve added it to the mix, and am finally using the API I asked for long ago.

The elmcity service now supports three major sources of events:

  1. A curated list of iCalendar feeds
  2. Eventful
  3. Upcoming

The Eventful and Upcoming sources are governed by three bits of Delicious-tagged metadata. For Keene, they are:


Both services support queries that, if written in English, would say: “Give me all the events within 15 miles of Keene.”

Won’t there be duplication? Sure, and here’s an example from the Keene calendar.

Sun 05:00 PM Caribbean Night with Steel Drum music
(eventful: Inn at East Hill Farm)

Sun 05:00 PM Caribbean Night
(upcoming: The Inn at East Hill Farm)

I regard this as a good problem to have. Seeing an event from multiple sources is infinitely better than never seeing it at all. Over time I’ll look for ways to coalesce these duplicates. But for now, given that the vast majority of events aren’t being posted online in any structured way, I like showcasing the many ways to do that.

Posted in Uncategorized

14 thoughts on “Revisiting FuseCal and Upcoming

  1. Hey Jon,

    A friend suggested that I ping you about some software called Calagator that I’ve set up for the Vancouver Tech community. Calagator is a project started by some Portland hackers to create a wiki-like collaborative event aggregator. You can see their install at, and I’ve got it running at

    It’s pretty cool, you can give it event feeds, and it’ll import all events in that feed. Or it’s easy to create events by hand. Give it a try, you can delete the events after.


  2. I have looked at Calagator, and it is indeed very cool. I think we are running on parallel and complementary tracks. From what I can tell, Calagator is:

    – An iCalendar aggregator, which includes its own Ruby-based iCalendar parser.

    – A database of events.

    – An application for posting/viewing/searching/subscribing events.

    – A service that’s tuned to the interests of tech communities.

    The elmcity project is:

    – An aggregator for iCalendar feeds, Eventful, Upcoming, and any other source of events that may be usefully available

    – A flow orchestrator, not a database.

    – An information hub, not an application.

    – A service that can support many different interest groups within a geographic community, as well as the community at large.

    I am explicitly not storing any event data because my aim is to show people in a variety of communities how to participate in pub/sub networks, as producers and consumers of feeds. The calendar domain is a useful one for this purpose, but it’s the underlying principle of syndication that I’m really trying to show and motivate.

    Similarly, I’m explicitly not storing any metadata but am instead managing it externally — for now, on Delicious. That’s because I want to show that collaborative curation is a mindset more than a toolset, and that if you adopt the mindset you’ll find that existing tools are already perfectly adequate.

    Points of collaboration could include:

    – iCalendar validation. I’ve run into some pathologies with iCalendar sources, and you probably have too. Here’s a place to document them, and to work toward a suite of tests that could support one or more public validators:

    – Cross-syndication. An elmcity curator in Vancouver or Portland or elsewhere could add the list of iCalendar feeds from a Calagator instance to the broader list that he or she was curating. Conversely a Calagator curator could add tech feeds found by an elmcity curator — though I guess it might be rare for the latter to discover a feed not already known to the former.

    Of course there’s no reason that Calagator has to be restricted to technically-minded folk. It could be adopted more broadly, and I hope it will be. If that happens, my hope would be that the adoption happens in a way that encourages people to materialize their own feeds, published on their own sites, wherever that’s feasible and appropriate.

    FWIW, here’s why I think that matters.

    Syndication-oriented architecture ( is a critical enabler for all sorts of things. But I’ve found that it’s a hard concept for people to grasp. In the case of a domain like this one, community events, people think that there has to be one authoritative bucket that holds everything. But there can never be a consensus about who controls that bucket, and in any case, people shouldn’t have to register there and re-enter information that they’re already maintaining for themselves.

    Instead of one bucket, I want there to be many hubs. Even within a community, there can appropriately be many, to support the various interest groups within the community. But the same decentralized set of feeds is flowing through all the hubs, then event publishers control their own information, the information can syndicate to wherever it’s needed, and we can become aware of the totality of what’s going on.

  3. Good stuff – I very much like the idea of many buckets, many feeds and communities filtering those feeds to improve the signal to noise.

    Don’t tell anyone, but I’m secretly hoping that a bunch of crafters or knitters or non-techies starting using :)

  4. Hey Jon,
    Thought I should chime in on FuseCal. Our long-term goal is to facilitate the flow of event information around the web and mobile ecosystem, and provide analytics on this information – kind of like a FeedBurner for event data. Harvesting (parsing) events is an important step in this process right now as most sites don’t use any standard format for events.

    We realize that the harvesting in FuseCal isn’t perfect yet. The theory is that as more and more people use FuseCal, we’ll have the data we need to improve the models and related technology for much broader, generalized harvesting. (We can also quite quickly write customized harvesters for specific sites and/or types of calendars.) On the flip side, we’re hopeful that new web sites will use ical or hcal for their events. We can thus converge more quickly on the ability to find, aggregate, edit, share and track a majority of web-based event and schedule data.

    The main challenge for us right now, as with most start-ups, is resources. We’d love to dedicate a couple of natural language processing PhD’s to the problem, but we’re not quite there yet :-(

    We’ll keep you posted….

    CEO, Public Display (makers of FuseCal)

  5. > We realize that the harvesting in FuseCal
    > isn’t perfect yet.

    It is, however, much improved! I revisited some calendars that it did not parse last time I tried, and had much better success. You can track my progress at

    Nice going!

  6. Bill and Jon, I’m curious what role (if any) you guys envision hCalendar playing in the web-based calendaring ecosystem going forward…

  7. Hi Dan,
    We love the idea of microformats like hCal (which is based on the iCal standard, as you probably know). We haven’t, however, seen hCal adopted very widely in the schedule and event world yet. My sense is that most folks who are listing events on their websites (rightly, in my opinion) feel that the primary objective is to get the information online and keep it current. I don’t think most webmasters, no less mere mortals, really have the time or inclination to go to the next level of thinking through how people want to interact with that information. So, they probably don’t spend a bunch of time tinkering with the event format.

    As the web continues maturing, new sites get launched, and older sites get revamped, I expect that we’ll see a gradual expansion of standardized formats in the schedule and event world. Certainly it would help if such standards were built into the various web tools. With Outlook, Google Calendar and Apple’s ICal now all on the iCal standard, it seems like there’s critical mass on the calendar (or, as an analogy, the ‘event reader’) side. So, generally speaking, I think iCal will happen, and that the hCal microformat will be part of that. I just think it’ll be at least a couple of years before we get meaningful uptake.

    All of the foregoing in my most humble opinion.


  8. > I just think it’ll be at least a couple
    > of years before we get meaningful uptake.

    We desperately needed Live Clipboard back in 2006 when Ray Ozzie announced and demonstrated it at ETech:

    And we still do.

    If I see an event on a web page, I should be able to copy it, and then paste it into a web app or a native app with equal ease. And vice versa.

    Crack that nut, and suddenly hCalendar becomes compellingly interesting.

    There are no real obstacles going webapp to webapp, except inertia, which of course /is/ a real obstacle. At one point Eventful was actually supporting Live Clipboard, but nobody else did. Including Microsoft, sadly.

    Going webapp to native app requires some bridging technology that Ray demoed, but has never been release — not for Windows, not for the Mac.

    Copy/paste between Outlook/Gcal/iCal and Eventful/Upcoming/blogs/websites would get hCal over the activation threshold real quick.

    Without that, though, I fear it will continue to languish in the semweb geek ghetto.

    If we had copy/paste, we’d run into some interesting semantic issues which I touched on in this screencast:

    Dealing with those issues would be a good problem to have. Unfortunately we’re not there yet.

  9. Doing a search for “Live Clipboard” and unsurprisingly ended up at Mr Udell’s blog.

    Its very disappointing that Live Clipboard never took off. I wonder if there’s any hope that the community will ever resurrect it!!


  10. Hey Jon, this is awesome. I found it after writing a blog post and figuring out if I thought it, some others probably did too.

    My event system is ridiculous right now. It’s a combination of a gmail filter of lists, text messages of things going on, facebook, twitter and paper calendars. All of these sources point back to some origin and should have just published the event in a syndicated format to begin with! I should mention I live in Brooklyn, which generates like, 20 or more events a day that I’m aware of.

    I think a proxy service to do screen scraping and validation is crucial. It sounds like that’s what FuseCal did.

  11. дешевые шлюхи проститутки москва волосатые проститутки москвы проститутки восток москва проститутки онлайн москва проститутки марьино москва

Leave a Reply