[Dev] calendar data model
Katie Capps Parlante
capps at osafoundation.org
Mon Sep 29 11:18:02 PDT 2003
Your point about projects is well taken, and we do intend to make a
"project" be an integral part of the out-of-the-box chandler schema.
Indeed, one might want to link "appointments" to "projects", one might
want to link all sorts of other items as well: "emails", "contacts", etc.
The data model should be flexible enough to allow you to model your
going-to-the-dentist use case the way you describe below. It will also
allow the simpler example, where various properties are on the
Marcus Sundman wrote:
> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
More information about the Dev