Knowledge-based Calendar System (KBCS)

This is a calendar application for a somewhat sophisticated end user. The envisioned end users are "people like computer science professors." These end users can program, though they may no longer do it very often. Moreover, they may or may not want to program in order for this calendar application to be used. In other words, most functionality must be readily available, however some way of extending the system without a lot of end user effort, be available.

The calendar should have the basic functionality of a typical calendar application. It should calculate and display the months, days of the week, dates, and years CORRECTLY. End users should be able to set appointments and optionally specify time durations of the appointments.

Unlike some calendaring applications, appointments should not force an end user to specify duration for an appointment. There should be a default possibility of a time placeholder without a time dimension (and without crashing the display of appointments). In addition to appointments on a particular date, appointments crossing over several dates should be possible.

Days should allow for a "title" as well as a set of appointments. I.e., if end users want to put in a holiday, they could put it in as a title. (Or, perhaps the entry is made as a "holiday" type of entry and it is just shown as a day’s title on the view).

Appointments and holidays should have "types" and "properties." These properties will determine display attributes and be the basis for other kinds of sophisticated functionality! Two "types" have been articulated implicitly already: appointment and holiday.

Properties of appointments should include (but not be limited to) tentative versus confirmed, optional versus obligatory, personal versus professional, and private versus public. Appointments should also include the name, location, estimated travel time, duration, as well as a title (a brief descriptor) and a description (optional but more detailed than a title). Appointments should also include an owner of the appointment. The default owner is the current end user. This non-obvious attribute would allow me to track appointments of colleagues, acquaintances, friends, family members, etc.

Properties of holidays should include (but not be limited to) association of the holiday: e.g., "American National," "European National," "Canadian National," "Christian-Catholic," "Christian-Protestant," "Jewish," "Buddhist," "Muslim," etc. Note, there could be multiple associations for holidays. E.g., in some European countries, some national holidays are Roman Catholic Holidays.

What will be unique about this calendar application is its flexibility and its knowledge-based implementation. Objects (such as days and appointments) with attributes (such as owner and duration) are a basic knowledge based as well as object-oriented paradigm. However, the customer prefers to think of these objects as pieces of knowledge and use a knowledge base substrate to store and retrieve objects in the anticipation of adding some sophisticated functionality such as implementing agents to assist with making appointments, even guessing likely used time slots. E.g., when is a likely time for a meeting with student Jane Doe? Perhaps the same time and date as a previous meeting? What is a likely time for a meeting with some random graduate student? Perhaps the same time as a meeting a previous day with a graduate student? Moreover, properties such as estimated travel time could prevent planning too tight a schedule. Intelligent agents could learn when the first appointment of a day comes. There are many possibilities.

The customer strongly urges the developers to look at http://protege.stanford.edu/ as a possible substrate for implementing the objects. The customer also strongly suggests the application be developed in Java for portability and easy extensibility. Moreover, the code should use good style (e.g., naming and other conventions, structured programming, separation of concerns, etc.) The final product must contain both a user manual and program documentation.

There are typical ways to display features of a calendar. One (inadequate) view is given below.

If you have any questions, e-mail to Dr. David Redmiles.

ICS125 FQ01 Project Opportunities
ICS125 FQ01
David F. Redmiles Home Page
Department of Information and Computer Science
University of California, Irvine CA 92717-3425