We've re-enabled support for Upcoming.org on our Auto-Submit feature. So if you want to create an event on Eventful.com and have it automatically posted to Upcoming.org as well, you can now do so again -- provided you have an Upcoming.org account.
We've implemented a de-duping capability using the Upcoming API -- so if you try to post an event on Upcoming and specify a venue that already exists on Upcoming, we do our best to use the Upcoming venue as opposed to create what would wind up being a copy of the venue. We've also implemented support for Upcoming's newly-released token-based authentication.
I'd like to thank everyone on the Upcoming team for the super responsiveness, cooperation, and overall willingness to work with us to make this happen. I hope we can continue to work together in achieve further levels of integration in 2006.
Along those lines, some thoughts, in the form of an open letter to all the companies in the emerging "event" space on the web:
One thing that's come out of this whole Auto-Submit experience is the clear need for an independent, web-wide standard way of publishing event data that is highly portable, highly detailed, and available to any aggregator that wants it. This goes beyond EVDB, or Upcoming, or Zvents, or any other company. The web still needs a totally open, portable way of letting any individual or organization announce their events to the world, enabling search engines and aggregators to help people find these events more readily.
We see two parts to the problem – notification, and choice of data container format.
In the blog world, we've seen blog software makers all cooperating on a ping API standard, meaning that whenever anyone posts a new article on their blog, it gets announced to ping servers automatically, enabling Technorati-style aggregator/search services to flourish, and, in turn, enabling blog discoverability to flourish.
This is what events need on the web. A way for event discovery to flourish through a widely adopted notification standard.
I'd like to see Upcoming, along with us, Zvents, and everyone else, publish public events to one or more ping servers that know how to deal with events, and let any other person or service subscribe to those ping servers.
The second part of the problem is an event data container format. The good ol' iCalendar format (RFC 2445) is one possible answer to this. This is the format that most calendaring apps use to externalize event data. But iCalendar has some drawbacks for public events; most notably, it has only minimal ability to represent location information. Through our participation in the CalConnect group, we're trying to eliminate these shortcomings. There are numerous other possibilities for event container formats, from microformats embedded in HTML documents, to RSS / ATOM, to brand-new XML formats.
We think the solution to the container format problem is to require that the ping message contain information about the format(s) of the available event data. This would allow the ping mechanism to continue to be used as event container formats evolve. In the interests of event discovery, having ping servers embrace multiple formats -- and letting the marketplace over time decide which it wants to use and which it doesn't -- is the best bet.
For a while the EVDB team has been kicking around an idea called SES, or Simple Event Sharing, which would be essentially something along the lines of what's described above. We already have the beginnings of a ping server. But there's lots more to do, and no one company is going to do (or own) it all. For all of this to work it needs to be open and something all the vendors agree to support.
Wanna work with us on this? I think it'd be a great project for us, Upcoming, Zvents, and any other events sites to achieve in 2006.
Let's do it!
Your point about event data formats is something we've been thinking about for a while. We build sites for quite a few major arts organisations here in the UK, so have quite a bit of knowledge of what makes up a good events database. We've always meant to turn this into a fully-fledged, open, XML schema, called EventML.
We really think events need their own XML solution - there is simply too much variance in the data to cram it all into an available format or microformat. A classic one that we often come across is how to handle recurring events - what we do is separate what the event is ('shows') from when they actually happen ('performances'), but this is a pretty major shift from the available formats out there.
I believe it's essential we all work together on this. The main challenge for all of us is to encourage content providers/users to create their own, rich content, in a format we can all use. From there, it's simply a matter of preference as to which interface a user opts for.
