Although I haven’t been able to confirm this officially yet, it looks like FuseCal, the HTML screen-scraping service that I’ve been using (and recommending) as a way to convert calendar-like web pages into iCalendar feeds, has shut down.
The web pages that FuseCal has been successfully processing, for several curators participating in the elmcity project, are listed below. They’re a kind of existence proof, validating the notion that unstructured calendar info — what people intuitively create — can be mechanically transformed into structured info that syndicates reliably.
I hope this service, or some future variant of it, will continue. It’s a really useful way to help people grasp the concept of publishing calendar feeds.
But in the long run, it’s a set of training wheels. Ultimately we need to teach people why and how to produce such feeds more directly. All of the event information shown below could be managed in a more structured way using calendar software that produces data feeds for syndication and web pages for browsing.
More broadly, incidents like this prompt us to consider the nature of the services ecosystem we’re all embedded in — as users and, increasingly, as co-creators. In the software business, developers have long since learned to evaluate the benefits and risks of “taking a dependency” on a component, library, or service. Users didn’t have to think too much about that. A software product that was discontinued would keep working perfectly well, maybe for years. But services can — and sometimes do — stop abruptly.
Since the elmcity project is embedded in a services ecosystem, as both a provider and a consumer, how should a curator evaluate service dependencies and their associated risks and benefits? Here are some guidelines.
Many eggs, many baskets
An instance of the calendar aggregator gathers events from three main sources: Eventful (service #1), Upcoming (service #2), and a curated set of iCalendar feeds. A subset of those feeds may (until recently) have been mediated by FuseCal (service #3). So there were three main service dependencies here, and that’s one form of diversification.
But the iCalendar feeds represent another, and more powerful, form of diversification. One may be served up by a Drupal system, one may be an ICS file posted from Outlook 2007, one may be an instance of Google Calendar. Each depends on its own supporting services, but the ecosystem is very diverse.
Data and service portability
The elmcity project isn’t a database of events, but rather an aggregator of feeds of events. What matters in this case is portability of metadata describing the feeds, as well as data describing events. The system depends on Delicious for the management of the metadata. But all this metadata is replicated to Azure for safekeeping.
Since the elmcity project does run on Azure, there’s clearly a strong dependence on that platform’s compute and storage services. But I could run the code on another host — even another cloud-based host, thanks to Amazon’s EC2 for Windows. Likewise I could store blobs and tables in Amazon’s S3 and SimpleDB.
Strategic choices
In this context, the use of FuseCal was a strategic choice. There isn’t a readily available replacement, and that’s a recipe for the sort of disruption we’ve just experienced. But since the system is diversified, that disruption is contained. Was the benefit provided by this unique service worth the cost of disruption? Some curators may disagree, but I think the answer is yes. It was really helpful to be able to show people that informational web pages are implicitly data feeds, and to show what can happen when those data feeds are made explicit.
Still, it was a crutch. Ultimately we want people to stand on their own two feet, and take direct control of the information they publish to the web. FuseCal had to guess which times went with which events, and sometimes guessed wrong. If you’re publishing the event, you want to state these facts unambiguously. And using a variety of methods, as I’ve shown, you can. Those methods are the real strategic choices. If you can publish your own data feed, simply and inexpensively, you should seize the opportunity to do so
Jon –
You’ve hit part of the wonder of web 2.0 – the ability to build distributed systems that fail in the way Leslie Lamport says
“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.”
Oh man. Epic loss. Fortunately I did not rely on fuseCal, but it may well have been an integral part of a future business model – or at least the public data mining functionality they provided. It’s too bad they were the only provider of this type of service and didn’t have time to mature a business model. This is exactly the kind of useful tool whose torch should be carried on by the open source movement – (and by “open source movement” I mean myself and anybody else who thinks gathering temporal information from wild unstructured data is worthwhile). It’s already been demonstrated to be a doable task…I’d like to think that its not even that original of an idea and that there might even be a FOSS project to get involved with.
Could not attach 2 files regarding Jon Udell’s article
“Living on Universal Time” from InfoWorld.com 10.06.03
Hello Jon:
Today I am cleaning and tossing old paper docs from my office.
But before I tossed an old copy of your article, I scanned it, digitally filed it and attached it to this blog
Your article struck a resonate chord that launched me on a quest for many years. The end result was the creation of a the ITZ~ChronStamp, a universal (alpha-numeric/left to right index) format that is friendly to humans and computers.
Over the years my quest became a mild obsession to develop a comprehensive ‘function’ that could be open-sourced and deal with the conflicting international Date-Time standards. Even the ISO-8601 has never fostered the needed paradigm change. So as you know, emails and schedules are still referencing UTC with an offset value that most folks don’t have a clue how to use it when they find it. I hope you might kindly visit: http://www.FCCSS.NET or
go directly to the International Time Zone ‘anthology’ at: http://www.fccss.net/ITZChronStamp.html
To make any headway with this issue, we must start teaching children how to calculate World Date & Time without paper and to really understand how simply the 24-ITZ’s actually work. To that end, new tools and maps are needed to replace those found on the web, in school and reference books. Showing children or adults old naval maps from the 17-1800’s that are irrelevant to the Internet and business world today, even though they were a big step forward in the days of Captain Bowditch and others sailing the oceans. (Note: if you see a map that defines a time zone with 7.5 degrees on either side, it will not help explain today’s ITZ’s that are even increments (360º/24=15º) of 15º longitude from the 180º IDL or the 0º Greenwich prime meridians. The eastern most edge of a zone determines the time for the entire zone.
I just wish I could visit with my 4th grade teacher Mrs. Jackson and explain that it was not her fault she was provided with such poor tools to work with – and that an inquiring 10-year old had intuitively known that something was not mathematically right about the maps found in most reference books then or now!
Regards,
DonWagner@fccss.net
770.395.6500
ITS Industry consultant
Atlanta, Georgia
ITZ: Z01#20091010SA~063022; NEW WORLD DAY 180º lon
UTC: Z13#20091009FR~183022; Zulu/Greenwich 0º lon
FROM: Z18^20091009FR~1430PM; Atlanta, Georgia, US
TO: Z21^20091009FR~1130AM; San Francisco, California, US
=============================================
C:\eveDFC\_DOC\U\-0002942\Z18^20091009FR~1432PM;LivingOnUniversalTime.rtf