What I’m thinking of:

1. Select the group of events in your calendaring program of choice.

2. Choose Publish (or whatever it’s called)

3. Supply destination information (directory, URL)

4. The application creates one .ics file for each event, an .ics file containing all the events, and an XML file with links to all of those; an XSL file is used to transform it into whatever HTML you like for viewing (yes, you could just go to XHTML I guess)

The point here is to make it painless to publish. What FuseCal does, it seems, is make it painless to subscribe to a calendar once published.

I think that’s a very good bet!

Jon-
This relates to something I wanted to clarify about my earlier comment. Joking aside, we do fully expect the info extraction aspects of FuseCal to become less important as people do embrace calendar data standards. That’s actually a very good thing for us, because the other parts of FuseCal – publishing and syndication tools, analytics, and the potential to monetize events through contextual analysis of the events – all become much more interesting when there is more structured event data available.

However, we’re stuck first with the problem of accumulating that mass of structured event data. For now, our answer is to create that structure ourselves, and I think it will be a long time before the need for that service completely disappears.

2. I posted to their site two XSLT files which transform iCalendar to XML and vice versa. The iCal->XML transform currently requires you to embed the iCalendar data in a small bit of XML to make it an actual ‘document’ processable by XSLT. These two files are freely usable by anyone, just provide attribution (see the comments). I personally believe in the power of XSL transforms in combination with XML to make all sorts of data usable in all sorts of ways.

3. The IETF workgroup on iCalendar simplification has been making headway as well (but XML is not in their charter at the moment).

To answer your first question, yes the feed will persist, as long as your calendar app continues to request updates. We do periodically clear out anonymous feeds that haven’t had any hits in a while. However, I’d still recommend registering an account, so that you can manage your feeds in the future and from other computers. If your browser session hasn’t yet expired, your existing feeds will automatically get added to the account you create. This will let you add and change event filters, tag your calendars and subscribe to tag feeds, embed your calendars into web pages, opt in to emails alerts about changing events, and more.

Automatically handling the look-ahead is on our (very long) todo list. In the meanwhile, one hack would be to choose a unique tag to represent that calendar. As you add the URL for each month of the calendar to FuseCal, you would use that tag and the events would be added to the corresponding tag feed. In that way, you can at least create a single feed with all the events you want.

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. I think you’re on the right track with waiting for the “teachable moments.” I’m not totally sure if it’s even possible to build a startup around providing those incentives, but I think it makes a lot of sense as a non-profit community project, which is part of the reason I recently founded the MashableCity.org project.

That said, I’d love to be proven wrong and shown how to make money while fighting the good fight!

cheers,
Matt

Thanks,
John

You already have! FuseCal is doing a better job than I was able to do with this:

http://www.libraryinsight.com/calendar.asp?jx=ea

I was too lazy to parse out the times, I only got dates. But you got it all. Excellent!

Will the FuseCal feed that I made persist even though I made it as an anon user?

One interesting detail here: I’ve run into a few places where it’s helpful to look ahead. So in this case, the current month is almost over, and you’d like to look ahead to:

http://www.libraryinsight.com/calendar.asp?sm=&jx=eap&nMonth=5&nYear=2008&x=3

I was doing that in my otherwise inferior scraper. It’d be nice to be able to give FuseCal a rule about looking ahead.

> If you have any feedback on how we can
> improve FuseCal

That’s hard to answer because ultimately I don’t think FuseCal should have to exist. In general, I would like to see the effort that’s being invested in reverse-engineering of web pages — at FuseCal, at EveryBlock, and elsewhere — spent on a) building systems that invite people to manage information better from the get-go, and b) enabling all the great things that would happen if they did.

Here in the real world, of course, what you are doing matters enormously, and will for a long time to come. How to build bridges from here to a very unevenly distributed future is a very interesting question, I’d be interested to know your thoughts.