Entry Is Labelled

I am doing an English 398N project and as part of that project my group has created a survey to determine the anticipated need and usage of an all-campus event and activity calendar

Some fellow sophomores and I have started an initiative (caleld the DO campaign) to produce a campus-wide activities calendar, resulting from some brainstorming at the Second Year Insitute. We've already approached VP Glenn Nichols about this and even have a programmer to do the coding. We'd be happy to get in touch with you, if you'd like!

It's sad that we have so many "calendars" on campus, and yet, none of them are a good enough service to reach the tipping point where everyone uses them.

Some people, when reading the above, undoubtedly think, "well, what we need is the one true calendaring application that everyone will use!" Other people may think, "we'll just make a University mandate that says everyone has to use this specific calendar." (Because that always works well — dictation to your customers and your users instead of providing them with services that they elect to use.)

When I hear about the problem, I think, "well, if all of the different calendars exposed their data, we could just aggregate them into one 'calendaring space.'" "That is, everyone gets to use their own little calendaring application/service/thing-a-ma-bob, and we provide a service that pulls all of them together for display." Basically, if each separate calendaring service exposed its data in an XML format such as RSS or Atom (or even in just a publicly exposed iCal/vCal format), we could build a service that spliced all of that disparate data together and displayed it in a calendar view. (Yea, this is the essence of Middleware.)

Back in the beginning of this summer when Greg first started working for us, he was supposed to do a project with the calendar.case.edu system. I wanted him to do precisely what I describe above — a calendaring aggregator system. With that framework available, we could both go off and develop plugins for some of the major calendaring apps (like the Oracle Calendar, WebEvents, Exchange, etc.) so that they would emit their data in RSS/Atom. Then, we just aggregate it all together in the calendar aggregator. But, the idea gained no traction and Greg ended up doing something else with the Oracle Calendar (I can't even remember what it was and don't believe it amounted to a deliverable) before he went on to do the Case Wiki and Case Central Authentication Service.

It's too bad the calendar aggregator was never able to get off the ground. Hopefully, the students out there right now talking in the forums can generate an idea like this.

Comments

Agreed. This is a real problem, and good APIs to allow aggregating all the events a la Planet Case would be an ideal solution. One problem is the fact that some (generally smaller) calendars amount to a static HTML page with events listed on it. It's more difficult to get useful data out of this than a more structured calendar framework.

SIS seems to have an interest in doing something to help conquer the "calendar problem." The main obstacle right now is determining what "something" ought to be.

One problem is the fact that some (generally smaller) calendars amount to a static HTML page with events listed on it. It's more difficult to get useful data out of this than a more structured calendar framework.

It's hard not to sound pessimistic, but it really is a tall order to create an aggregater that combines so many calendars with not a single standard between any of them. Has ITS considered hiring a team of students for the sole purpose of fixing this problem? Experiential learning at its best.

Some calendars would remain and get aggregated, others would get asked to use the new system. In any case, do you think this type of project requires an ITS stamp of approval?

it really is a tall order to create an aggregater that combines so many calendars with not a single standard between any of them.

Bah, it's not that hard. Whatever Syndication Feed library you use (like XML::Feed) abstracts away whether the feed is RSS/RDF/Atom. So, that doesn't matter. The only one you have to worry about is iCal. But, it's simple enough to convert iCal -> Atom/RDF and then just process that through your standard Feed lib just like you did with the other feeds.

Processing hCalendar would get hairy, so I wouldn't do it (at least, not until v2.0).

Has ITS considered hiring a team of students for the sole purpose of fixing this problem?

No. Like I said, I could never get the idea to have any traction.

others would get asked to use the new system.

The system would be a read-only thing (at least, at first). Those calendars that emitted RSS/RDF/Atom/iCal could parcipitate. Those that didn't... no harm, no foul. But if they wanted to, all they would need is a little plugin that emitted the data and then the7 get play along, too. That's the beauty of XML over HTTP.

This is a middleware job. It shouldn't matter what calendar application people use as long as the data is exposed to be aggregated.

The problem here is once you have an aggregated calendar, how do you filter the events? Again, this is where middleware comes in. We need to establish people's relations and hence relevance to the events in a calendar. You can use LDAP to store info about people and then selectively display events based upon their properties in LDAP. You can use web services to accomplish the same. Aggregating everything is only part of the solution, but it is a necessary first step.

Is there a tool to convert iCal to XML? If so, can someone provide a link? I know about RDF Calendar and XCalendar, but I can't find any tools to go between everything.

Automagically figuring out what events a person might be interested in would be nice, but I don't think it's necessary. Stored preferences in a database specific to the aggregator app would be sufficient to let people hide what they don't want to see. These could be published back to LDAP or made available via a web services API at some point in the future if other apps need access.

xCal is a 1:1 mapping of iCal into XML. It sounds like work on xCal has stopped.

RDF Calendar - interesting, but maybe overkill if all we want to do is display events on a Web page and allow importing into calendar apps. [Are there other applications on campus currently using RDF for anything - calendars or otherwise?]

RSS Event module - may be a good format to be able to parse, but perhaps not as useful to emit this format compared to a calendar-specific format like iCal.

As a temporary solution, how about transforming all the calendars to iCalendar format (a useful thing to be able to do anyway), putting the iCal files on a server, and running an instance of PHP iCalendar?

I'm willing to help with such a project, if it's going to be done outside ITS. (After finals, anyway.)