[Dev] calendar data model
sundman at iki.fi
Thu Sep 25 19:11:37 PDT 2003
Why is an "appointment" the base for calendar entries? In my experience an
appointment is almost always a part of something larger.
I might, for example, be attending a course. The course has a number of
lectures and a final exam. These are appointments and have various
attributes, such as time and location. However, the appointments are all part
of the course which itself has a number of attributes, such as lecturer and
web page address. Naturally these two concepts should be closely linked (at
least in the UI); when looking at an appointment you often also want to look
at the course details and when looking at the course you often want to have
an overview of the "appointments" in the course.
Most appointments seem to be of this kind, even many one-time appointments.
E.g., going to the dentist might be a one-time appointment (at least that's
what I always hope for), but it is still only a part of the larger concept of
"going to the dentist" where you also might want to have attributes that
aren't directly related to the actual appointment. Let's say that the dentist
decides that a second appointment is needed. Then you need to add a second
appointment to the "going-to-the-dentist project". If those were just single
appointments (i.e., completely unrelated), as they would be in most
calendars, you'd have to copy almost all attributes (pretty much everything
except date and time) from the first one into the second one.
So what I'm proposing is to have a "project" (or similar) concept that is very
closely related to the "appointment" concept. Appointments could then be
grouped into a project, which is an entity of its own. This way the
appointment datatype could also be simplified, since much of what people
normally cram into an appointment could (and should) instead be moved to the
project that the appointment is part of.
Then you could also have project templates, such as "course", that define
default attributes and appointment types.
- Marcus Sundman
More information about the Dev