This description of Chandler from Kapor’s weblog sounds very much like OpenACS’ ACS Objects. Judging by the comments on his entry, apparently it also sounds like how many other systems are designed. Object-oriented, anyone?
The fundamental way data is stored in Chandler is as a collection of items, also known as a repository. Every individual email is represented by an item, as is every meeting on a calendar, and every contact. Not only that but every attachment, document, and annotation is also an item. In short, each piece of content is represented as an item.
An item contains a set of elements, which can be thought of as a collection of attributes and their values as well as relationships to other items along with a “payload”. For example, attributes of an email item would include its sender, the date sent, the subject, and other information which is represented in the header lines of the email itself. The “payload” is the body of the email. Similarly, attributes of a meeting item include its start time, end time, location, participants, etc. An item may have a relationship to another item, as in two emails which constitute part of a thread.
By treating items as the first-class elements of data, it is then possible for the user to obtain an integrated view of all the information in her universe. One simple feature which takes advantage of this is that when you use Chandler you will never have to look in multiple places to find what you’re looking for. In today’s world, you use your PIM to look for information sent by email, and you use a file manager to locate information contained in a document stored as a file. You may have to use other tools to find other types of information.