Hi Arjun -- thanks! I've now downloaded (checked out) the calendard-module. The data model does not seem to have changed significantly from the one I downloaded (4.5b1).
Here are the comments I made about our changes to the data model in a document I've written on at times the past couple of days (hope it gives meaning even when copied from its context):
Changes from the ACS version
First of all: All table and package names are converted to our naming standard.
We have removed the CALENDERITEM of the ACS model as it was limiting the extendibility of EVENT and not adding any value. The table is replaced with a table EVENTCALENDARMAP which tells which events belong to each calendar. This also makes it possible to link a single event to several calendars which seems to be a good idea.
We have used the representation of a range of time intervals from ACS. However, we have moved this "one level up" so that TIMESPAN is related to OBJECT instead of EVENT. This is done to make reuse of service-layer code easier (scheduling maybe being the prime example). Since the EVENT has a is-a relationship to OBJECT this should not have any particular side effects (other than some minor changes in PL/SQL).
We will introduce a PARTY called RESOURCE which will make it easier to treat resources and users as equals when implementing scheduling. It will also make functionality such as "view the meeting room's calendar" as easy as viewing a user's calendar.