Yesterday Bill Rawlinson, the elmcity curator for Huntington, WV, noticed something odd about an event that showed up on Eventful.com:
Here’s the example: http://eventful.com/huntington/events/allman-brothers-/E0-001-020736056-0. It appears the Allman Brothers were in concert today, but I’m pretty sure they weren’t.
I’m pretty sure they weren’t either. At AllmanBrothersBand.com it says they were in Nashville on October 14. But if that’s true, Eventful isn’t the only site that got it wrong date. So, apparently, did a number of event-gathering and ticket-selling sites. Here are couple of examples I found.
In cases like these it’s hard to nail down the provenance of a “fact” such as Allman Brothers, Huntington WV, October 14 2009. There is clearly syndication going on, but who’s upstream and who’s downstream? How is the network of feeds interconnected? Which is the authoritative source?
I know what the answer to all these questions should be. The Allman Brothers themselves should be the authoritative source, and everyone else should syndicate from them.
If AllmanBrothersBand.com published its schedule as calendar data rather than as calendarish web pages, the organization could control the data. Was there originally a concert planned for Huntington on the 14th? I don’t know, but say for the sake of argument there was. The Allman Brothers calendarish web page cannot effectively propagate a change of plan.
An iCalendar feed, on the other hand, could. But calendarish web page are almost never alternately available as machine-readable iCalendar data that can reliably syndicate.
Looking under the covers, I see that AllmanBrothersBand.com is a PostNuke site. Are there calendar modules for PostNuke that export iCalendar? None of the ones that I found seem to.
Why don’t more content management systems make event information available as useful data? Why do they instead advertise things like XHTML compliance and not-very-useful RSS feeds? Because, chicken-and-egg, nobody ever seems to expect an iCalendar feed.
If we can change that expectation, a nice chunk of the real-world semantic web will fall into place. And it won’t require RDFa or SPARQL or ontologies. Just good old RFC2445, right under our noses the whole time, if only we would open our eyes and look.
Jon, it’s amazing how easy this is to see once you understand it. There could be an amazing interweb of event information if we can drive adoption forward.
\\Greg
Thanks Greg. I really think so, obviously. Of course you can’t really drive adoption because it has a mind of its own. So the real trick I still need to learn is how to invite it in a compelling way.
I think I’ve posted this before – but what seems to be missing are ‘dead simple’ tools to take a list of events and publish them as iCalendar-enabled web pages. In my opinion, the tool would enable someone to select multiple events from somewhere (Outlook, spreadsheet, .csv, whatever) for N events publish to one site N+1 .ics files, one for each event, one containing all events, AND an XML file describing them with a reference to a matching stylesheet (to enable HTML viewing of the events too).
The iCalendar files could be eliminated if browsers and javascript enabled you to open text+icalendar files but the last I checked you could only do an open on text.
“what seems to be missing are ‘dead simple’ tools to take a list of events and publish them as iCalendar-enabled web pages”
Yes, a critical capability. It already exists in at least two places that are web-based and free:
1. Google Calendar
2. Windows Live Calendar
Both of these can ingest data from calendar software, and publish to ICS and HTML endpoints.
“Outlook, spreadsheet, .csv, whatever”
Here I would quibble. The source should be one of the many calendar programs that emit iCalendar data. That’s the only reliable exchange pattern. With a spreadsheet, a csv, or a ‘whatever’ there’s no standard interpretation of what those files contain.