kgrant@.com (Ken Grant) (01/09/90)
In article <90007.095243UH2@PSUVM.BITNET> UH2@PSUVM.BITNET (Lee Sailer) writes: > >Would someone offer a summary of the Information Lens, and perhaps a >good reference or two? Thanks. > > lee This will be a pretty terse summary (I'm busy today) - I can supply more details later if there is interest. The Information Lens project at MIT started from the realization that members of mature electronic mail communities often suffer from information overload. It is easy to join a few distribution lists and be overwhelmed by the mail traffic. We thought it would be nice if your mail system could help you by sorting, prioritizing, and otherwise processing your mail. In I.Lens messages are actually instantiated objects with a type. A message type inherits attributes and so on from its ancestors. The messages are presented to the user (and mail transport) as semi-structured text. At the root of the message tree there is the type Message, which has fields/attributes such as To, From, Subject, and so forth. A specialized message type, such as Meeting Announcement, inherits the standard header fields from Message, some fields from Announcement (such as an Expiration Date), and then adds fields for things like Meeting Time, Meeting Place, and so on. A user can customize default and alternative values for each field, and message construction is facilitated through the use of a template-oriented message editor. Users can also create new message types to facilitate their work. Thus, a special flavor of Meeting Announcement is the Lens Group Meeting Announcement, which has suitable defaults for the where/when/what part of the Meeting Announcement. On the receiving end, users are able to construct rules which process their mail based on type, values of attributes, and so forth. Messages from "the outside world" can always be classified as being of type Message, and may be more finely classified if the user's rules so specify. The action part of the rule may specify that the message be filed (into a hierarchical folder scheme), deleted, or even run an arbitrary procedure. By using their own message types and rules a group can create custom applications. For example, a scheduling application has a few special message types, and some special rule processing to allow access to the user's on-line calender. The second article referenced below speaks to this notion. Finally, the mail system allows messages to be marked as public (e.g. I don't care who reads this). Users can provide rules to the mail service expressing their interests, and the system uses these rules to find public messages that the user has not seen and which they've expressed an interest in. The following pair of articles are a good place to start, and should be reasonably easy to get yer hands on: Malone, T.W., Grant, K.R., Turbak, F.A., Brobst, S.A., and Cohen, M.D. Intelligent information sharing systems, Communications of the ACM, 1987, 30, 390-402. Malone, T.W., Grant, K.R., Lai, K.Y., Rao, R. and Rosenblitt, D.A. Semi-structured messages are surprisingly useful for computer supported coordination, ACM Transactions on Office Information Systems, 5, 115-131. (Reprinted in I. Greif (Ed.), Computer Supported Cooperative Work, Los Altos, CA: Morgan Kaufmann Publishers, 1988). cheers, kg Internet: kgrant%oracle.com@apple.com kgrant@oracle.com (if your mailer groks MX records) UUCP: ...{hplabs,apple,uunet}!oracle!kgrant USMail: Oracle Corporation, 20 Davis Dr, Belmont CA 94002