[Dev] calendar data model

Katie Capps Parlante capps at osafoundation.org
Mon Sep 29 11:18:02 PDT 2003

Hi Marcus,

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 
appointment itself.


Marcus Sundman wrote:

> Hi,
> 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
> http://lists.osafoundation.org/mailman/listinfo/dev

More information about the Dev mailing list