Using UW Calendar
August 2006 - Current status of UW Calendar and this website:
The UW Calendar project has evolved into Bedework. Please see the Bedework website for current code and updates. We will continue to keep this website up as an archive of the status of UW Calendar as of August 2006.
The UW Calendar project is building an open-source
calendaring system for higher education. UW Calendar will
support personal, public and group events, use existing open
standards, and support web-based and other forms of access,
- August 2006
Bedework 3.1, the successor to UW Calendar, has been released. Please see the Bedework website for current code and updates.
- August 2005
A new Frequently Asked Questions document
(largely written by Gary Schwartz, Mike Douglass, and Arlen
Johnson of RPI) has been added to the website. The master copy
will be kept in CVS under the docs directory.
Another fairly up-to-date version will be available on the
RPI CCT website
- July 2005
- June 2005
People affiliated with a college or university typically must
keep track of a multitude of calendars. Consider Joan, a graduate
student at a university. Joan is taking three classes and working
with a research group. To keep track of all the events in her day,
Joan must follow the university's academic calendar, her
department's calendar (for colloquia and seminars), a calendar for
each of her three classes, the calendar for her research group, and
her private calendar (for dental check-ups, etc.). If she has any
outside interests, such as playing on an intramural sports team,
each of these will have its own calendar. Finally, there are likely
to be many other events Joan might be interested in attending, but
never hears about. Clearly, Joan's life would be easier if all
these calendars were available in a single system.
Each person at a college or university will have different
calendaring needs. A staff member, for example, will be more
dependent on group calendaring, a freshman probably less so. Some
staff and faculty will need to schedule events with people outside
the institution, and might need to have some of their scheduling
done by an assistant. But all users would benefit from an
institution-wide system that allows users to view and manage their
public, private and group events in one place.
An institution, department, or individual may already have
partially solved their calendaring problem, so any new calendaring
system must be modular and work with other systems. For example,
all institutions keep events such as class schedules in a central
system already, and it would be unwise to duplicate these events in
another system. Other current partial solutions might include a
commercial group calendaring system, a department's set of web
pages for colloquia, or a person's handheld computer. A large part
of the calendaring problem is integrating as many of these systems
UW Calendar will consist of many components (see
the System Architecture diagram). We can
classify these components as follows:
- A server (also sometimes called a calendar
store or calendar service). The server holds events and other
similar objects. UW Calendar will include its own standalone
server running using a relational database. In addition, there may
already be stores of events on campus which, using open standards,
can be made to work with the UW Calendar system. Thus,
conceptually there may be multiple servers in the system.
- An aggregator. This component takes the output
of multiple servers and combines them into what seems like a single
source of data. For example, to construct a student's calendar for
today, the aggregator might get data from the class schedule
database and a separate database of personal events. Applications
that only deal with data from one source, of course, need not use
- The Big Four applications:
- A personal calendar application
- A public events entry application. This would
typically only be usable by a subset of people, particularly if
only "official" public events can be stored on the server.
- A public events display application. This
would typically be usable by anyone, including members of the
general public, to view events at the institution.
- A group calendaring application.
- Numerous smaller applications and widgets. For example:
- A version of a person's calendar suitable for inclusion in a
- Tools to create a web page corresponding to a subset of public
events (e.g., Upcoming English department colloquia)
- An 'add this event to my calendar' tool, suitable for use via
clicking on an icon next to a public event displayed on the
- Similarly, 'add my class schedule' or 'add my finals schedule'
- Similarly, a tool to 'subscribe' a user to events of a
particular kind, such as author readings sponsored by the
bookstore. Note that this would include events that haven't been
added yet as well as those that currently exist.
- Tools to sync a person's calendar with a copy on another
system, such as a handheld device.
Some of the above components might overlap with each other, or
even be combined into a single tool. For example, the 'add this
event to my calendar' widget would almost certainly appear in the
public events display application, while group calendaring might be
folded into the personal calendaring application.
complete list of features planned for UW Calendar,
see the requirements document.
UW Calendar is based on UW Calendar, a
University of Washington system with the following features:
- A database for storing general events, with a schema derived
from the iCalendar standard (iCal). For a
detailed description of this standard, see RFC 2445.
- Code to convert UW Calendar events to iCal (and
- A web-based personal calendaring application.
- A public events entry system.
- A public events display system.
- Integration of public and private calendars.
- A service to generate a peephole view of a person's calendar,
suitable for display in MyUW, the University of
Washington's portal. (Note that MyUW is not based on
UW Calendar is written in Java. The current code download contains items
The University of Washington licenses the source code of
UW Calendar under a "BSD-style" open
source license. This license permits use of the source code by
anyone for any purpose, including commercial purposes, requiring
only that acknowledgment be given. As the package evolves and other
institutions and individuals contribute to the package, license
terms for package parts and for the package as a whole will be an
issue about which the project participants must achieve consensus.
The University of Washington is, however, committed to preserving
these license terms for its contributions, and we will work to
insure that the BSD-style license terms will continue to be used
for this package indefinitely.
Authors of significant contributions to the UW Calendar
project must have a signed copy of the
Contributor License Agreement on file
at the University of Washington. This document assigns the
University of Washington a copyright license on your contributions
to the project. All authors still retain their copyrights. This
agreement serves at least two purposes. First, it provides
clear proof that the contributions can be distributed as part
of the UW Calendar project. Second, should someone decide
to take some sort of legal action against the project, the
University of Washington could step forward immediately as the
party defending UW Calendar, instead of having to track down
all the authors.
UW Calendar will be a total calendaring and events system
for institutions of higher learning. It will store and retrieve
private events, official and unofficial public events, and group
events, as well as schedules for resources such as rooms,
equipment, and computer time. It will include applications to view
and edit any useful calendar that can be derived from these events,
including calendars oriented to a single person, a single resource,
a group of people, or a large entity such as a department. It will
include applications to facilitate group scheduling, including
groups whose members span institutions using different instances of
UW Calendar will be open source and platform independent.
It will use existing open standards where possible, especially the
standards of the IETF Calendaring and
Scheduling Working Group. It will support integration with
other systems and middleware, particularly open systems such as uPortal
Shibboleth. It will be modular, so an institution can
deploy only the components it needs, and extensible, so an
institution can build any new component it needs.