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.

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

-Jamie

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

http://www.infoworld.com/article/06/03/15/76381_12OPstrategic_1.html

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:

http://weblog.infoworld.com/udell/2006/04/03.html

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

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.

bill

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 http://delicious.com/elmcity.

Nice going!

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….

Bill
CEO, Public Display (makers of FuseCal)

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

- 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: http://icalvalid.wikidot.com/.

- 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 (http://blog.jonudell.net/2007/09/11/a-conversation-with-rohit-khare-about-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.

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 calagator.org, and I’ve got it running at vancal.org.

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.

Cheers,
Luke