Venice: Content-Based Information Management for Electronic Mail

Transcription

1 Venice: Content-Based Information Management for Electronic Mail Kenrick Mock, JF2-74, Robert Adams, JF Lynice Spangler, JF2-74, Abstract Electronic mail users are currently spending significant time sorting, searching, and managing their . The Venice project attempts to transfer the burden of managing from the user to the computer. Venice is composed of a set of evaluators and extractors that analyzes incoming mail and assigns mail to semantic categories. Under this paradigm, mail may belong to several categories, and multiple categories may be used as cues to aid retrieval of an individual. In addition to the evaluators, Venice also incorporates a unique user interface that supports the visualization of s within each category. Built upon Microsoft s interface, Venice is also compatible with a variety of mail transports, including POP, SMTP, and CC: Mail. The project is currently in the prototype stage and initial results appear promising. Introduction Electronic mail has revolutionized the way that companies and individuals communicate with one another. As a result, the problem of information overload has become more significant. Time Magazine estimates that 776 billion s were sent in 994, 2.6 trillion will be sent in 997, and 6.6 trillion s will be sent in 2000 []. Today, it is not uncommon for users to receive over 200 s per day. The goal of the Venice project is to ease information overload and enhance information retrieval through new methods for information management and visualization. To accomplish these goals, Venice incorporates a new paradigm. Rather than the traditional paradigm of an inbox and associated folders, Venice has no inbox and categories or topics in place of folders. Topics address the content of a. For example, an about a meeting on intelligent agents might match two topics, one for Meetings and another for Agents. To retrieve this, the user first selects one of the two topics. To narrow the number of s retrieved she may then select additional topics. Only the s that match all selected topics are displayed. By performing incremental selections, the user is creating a real-time visual query. The query retrieves related s automatically without the need to switch among search-based dialog boxes. A sample of other topics included in Venice are AR s, Important, URL s, Bulk Mail, and various date selection topics. The topic buttons themselves depict a graphical representation of the volume of pertaining to each topic over time. The graphic display also provides colorcodes to highlight unread articles or currently selected articles. This feature provides feedback as to status of each topic through a single glance. Figure shows a partial screenshot of the major Venice components. The topic selection buttons are on the left and the list of mail items is on the right. The current query retrieves mail s containing URL s that are not in the Mail List category. The blue graph within the topic buttons indicates volume of mail over time, and the orange bar indicates the current selection. Figure : Venice UI components for topic selection and mail list view Venice automatically learns how to classify s into topics. The actual classification mechanism is a

2 hybrid algorithm. The hybrid classifier employs both pre-calculated algorithms and machine learning algorithms that adapt to a user s preferences and can learn new topics. System Components In order to perform the tasks described above, Venice must address a number of software and research issues. First, the underlying architecture must be designed to support retrieval, update, and topic selection. Second, information agents must be designed to extract and evaluate what topics apply to a particular . Third, the user interface and presentation must facilitate visualization of the data space and make information management easy and effective. System Architecture Venice lies on top of Microsoft s interface. is a messaging interface specification used by Microsoft s Exchange and Outlook [2]. The advantage of is that it provides a layer of encapsulation that allows Venice to operate across a variety of mail transport systems (e.g. CC: Mail, SMTP). The significant components of Venice include the interface, extractors, evaluators, document viewer, and a database store that holds features. These components are depicted in figure 2. The extractors pull relevant information out of articles into distinguishing features. For example, an URL might be a distinguishing feature, as may particular keywords, addresses, or the names of people. Once features have been extracted, they are placed in secondary storage. While some of these features are useful for direct retrieval (e.g., dates or names), often a more detailed analysis of the features needs to be made to determine if a belongs to a particular topic. An evaluator performs the detailed analysis. After features have been extracted, the features are evaluated so that Venice knows which s belong to what topics. This is accomplished through a set of evaluator modules. Each evaluator operates upon a new article, resulting in a set of attributes that indicate how closely the article applies to each topic. For example, an article about a meeting might have a Meeting attribute with a weight of, while its Humor attribute might have a weight of 0. When evaluation is completed, the results are displayed to the user through the document viewer. The entire process requires significant communications between components. Moreover, the evaluation agents are research projects in themselves, making the entire design non-trivial.... Inbox Folder Folder Folder... Interface Interface EvalRunner Data Store Outlook API Figure 2 : Venice Architecture Venice Evaluator Evaluator Evaluator Microsoft defined the ( Mail Application Programming Interface ) as a universal method for user interface applications to connect to multiple mail transport systems, mail storage systems, and address directory services. Built as a COM (Microsoft s Component Object Model) component, replacement with an interface to a different architecture is possible without disturbing the rest of the Venice components. By building on top of, Venice does not have to implement any mail transport operations, does not have to create or manage any mail folders, and does not have to implement any address books or directories. Microsoft provides services the underlying libraries that do the actual connection to the mail services for SMTP mail and Exchange mail. Microsoft also provides a to VIM interface which, when used with the Lotus VIM libraries, allows connection to cc:mail services, folders, and directories. A cc:mail user who is installing and initializing Venice, would import all of her mail that is in existing cc:mail folders, connect and use their existing cc:mail accounts and address, and have access to the cc:mail directory of addresses. In fact, since Venice stores all of the in the folders, they are actually stored in the cc:mail folders so a user could switch back and forth between Venice and cc:mail without loosing any s. When a user starts with Venice, she would import all of her existing mail. Venice uses to read all the headers and bodies of existing and extracts and evaluates the s. The actual s are left in the folders and Venice creates another database of features and attributes of each of the s. Its ID ties these attributes to the real... Viewer 2

3 . With the ID, the can be opened, read and replied to. In the event that data changes while Venice is not running, Venice will synchronize all data with local Venice features each time the application is executed. Although most methods in the Interface serve the purpose of requesting information, two methods exist for the purpose of sending information to. One allows the caller to register for a notification from through the interface, which allows Venice to receive a signal when new mail arrives. The other is a generic method to send mail. In addition to allowing Venice to send user-generated mail, the send mail interface is also used to programmatically report statistical usage information from Venice to a central gatherer. The usage information collected by the gatherer may then be used to analyze what features are being used, how accurate Venice is classifying mail, etc. The user interface for reading and sending mail is handled via Microsoft Outlook s API. Extractors Venice currently extracts the following feature information from each article: author and mail recipients, dates, and names, addresses, URLs, compound phrases, stylistic features and direct keywords. The header information for each typically includes items such as the sender, urgency, status, recipients, and subject line. These are used directly as features for classification. As an additional abstraction, the number of recipients is also extracted as a feature that is useful for classifying s in the Bulk Mail category. Extracting some of these features is trivial. For example, computing the number of recipients only requires a simple traversal of the string containing recipient addresses. However, other features such as dates and names are less trivial due to ambiguity and the use of context. If Jack appears in a, is it a name or does it refer to a car jack or perhaps a Jack from a deck of cards? Similarly, if a contains 2-4 does this mean 2:00PM to 4:00PM, or does it mean February 4 th, or does it mean April 2 (using the European date forma? Context tracking is necessary to disambiguate the correct interpretation. Venice incorporates a grammar with date heuristics that approximate the context in order to extract dates. For example, days of the week by themselves are assumed to be the upcoming date. Similarly, tokens such as : are examined to determine whether or not an item is a date or a time. For example, Venice may begin parsing 0-4 as a date, but then invalidates the date when the keyword PM is encountered. Additionally, constraints such as what constitutes valid dates are examined. This allows the disambiguation of some European dates that are not valid American dates, such as 8/4/997. Since 8 is not a valid month, Venice assumed it will be a day and then expects a month to follow. Rules such as these have all been incorporated into the Venice date grammar. While not perfect, experimental results on a test corpus of 00 s correctly classified 90% of the dates within the articles. Currently, names are extracted based upon a precalculated list of common names. This list contains 2000 names, and Venice will assume that a word is a name if it is capitalized and exists in the name lis t. While this produces some false hits (e.g., June is a name that is also a month), the algorithm errs on the side of producing false positives rather than false negatives. Direct keywords from the text may also be extracted and forms the primary basis for the learning algorithms. Venice uses words from the first 4K of an article in vector comparisons to determine relevancy to another article or profile. These words are first passed through a stop list, a list that contains common words such as the, to remove non-informative words. Next, the words are passed through a stemmer, an algorithm that removes stems from words. This allows words such as apples and apple to be treated as the same word. The resulting keywords are then stored as features for the evaluators. For future work, syntactic and knowledge-based methods would prove useful for extracting particular items [4,5]. For example, knowledge about meetings and dates helps narrow down what text refers to a meeting and can extract the actual date of the meeting with the help of a grammar and knowledge of date events. Finally, stylistic features such as word to token ratio, sentence length, and parts-of-speech used may also be useful features to determine topic categories or user interest [3]. Evaluators The purpose of evaluation is to determine what topics apply to an article based upon the features extracted from the article. In addition to hand-coded rules, a number of classic machine-learning technologies may be employed to perform classification. Typical classification techniques include Bayesian induction, nearest neighbor classifiers, neural networks, fuzzy logic, and genetic algorithms. Venice currently employs a combination of hand-coded rules and a simple nearest neighbor evaluator. We hypothesize that the hybrid combination of hand-coded and fuzzy evaluation, 3

4 together with information visualization techniques, results in a powerful information retrieval system that supports generalization and accuracy. In the future, additional classification algorithms will be examined. The Intel Relevance SDK was examined but was difficult to incorporate into Venice since the SDK is designed to compute relevance and not categorization. Nevertheless, we have not ruled out the possibility of incorporating the Relevance SDK technology. The hand-coded rules implemented in Venice apply to pre-authored categories included in the application. A sample of the categories pre-authored in Venice include Mail List, Meetings, Important, Presentations, Action Items, and Status Reports. The encoded rules scan for keywords and phrases that have a high correlation with a particular topic. For example, the keyword ListServ is indicative of a Mail List topic, while the phrase You should and Can you? is indicative of the Action Items topic. An engineer that examined existing articles and abstracted the relevant data determined relevant keywords and phrases. While this method is ad hoc, it does allow Venice to incorporate pre-existing knowledge that is likely to be extremely relevant. In addition to the hand-coded rules, a machine-learning nearest neighbor algorithm is also employed to classify articles into topics. This is required in order to evaluate content that is unique to a particular individual and impossible to pre-author. The learning algorithm also complements the encoded rules in the event that the rules fail. The nearest neighbor algorithm implemented in Venice operates upon statistics gathered from each feature. These statistics are based upon the mutual information metric between a feature and the category [7]. The mutual information I(x; between feature x and topic t is derived from Bayes Theorem and is defined as: P( x, I( x; = log P( x) P( If x and t are highly correlated, the result will be a large positive value. However, if x and t are not correlated, the mutual information is a value that is a small negative number. This equation is simplified in Venice. Currently, Venice does not care how strongly a belongs in one topic versus another. For example, if a mail item belongs to both the Action Items and Meetings categories, Venice does not care if the is more strongly Action Items than it is Meetings. Venice only needs to know if the mail belongs in each category or not. Consequently, since mail is not compared across topics, the P( probability of a topic will always be a constant factor and can be dropped from the equation. Similarly, the logarithm is not performed since this is merely a scaling factor. The mutual information value can be computed for every feature with respect to every topic by gathering statistics regarding the frequency of the feature, and the frequency the feature occurs in the topic. The computed mutual information values form profiles for each topic. Features that have a large mutual information for a topic become the relevant features for that topic s profile. To classify a new article, the article is decomposed into features and those features are compared to the features in each topic s profile. The nearest neighbor algorithm is a linear classifier that computes a distance between the feature vector for an article compared to the feature vector for a topic. If the distance is less than a threshold amount, then the article is classified as belonging to the topic. We are currently experimenting with two methods to perform the nearest neighbor classification algorithm. The first algorithm computes a relevance value for R # features( i= i= ( m, = # features( Top I( x(, ( I ( x(*), ) m by summing the mutual information values extracted from m with respect to each topic and then divides by the top values for the topic: After dividing by the top mutual information values for a topic regardless of feature, the relevance is scaled and guaranteed to be no larger than. To determine whether or not an article belongs to a topic becomes a matter of checking whether or not R is greater than a fixed threshold, say 0.5. If the algorithm classifies incorrectly, the user will have to manually move s into or out of the topic. This adjusts the statistical data that determines the mutual information values. Eventually enough features will be updated so that the same article will result in a R value that is on the other side of the threshold, resulting in a different classification. The second algorithm to determine category membership simply computes R by summing the mutual information values: i i 4

5 R( m, = # features( i= If R is greater than a variable threshold T, then m belongs to topic t. The difficulty arises in calculating T, a threshold that varies for every topic. One technique to quickly compute the threshold is through random sampling. U s that are known to not be in t are randomly selected, and V s that are known to be in t are randomly selected. The threshold T is computed via: T = x U This algorithm then selects a threshold somewhere between s known to be in t, and those known to not be in t. The first algorithm maps the relevance values into a fixed range for classification, while the second algorithm computes a dynamic threshold. Testing is still underway to better determine the merits of each algorithm. We anticipate the first algorithm to adapt more slowly than the second algorithm, but also to be more resistant to change and less likely to learn erroneous categorizations. The second algorithm should learn faster but may also make more errors, and it requires a sample size sufficient to cover the space of topic classifications. User Interface I ( x(, R( x, + R( y, 2 y V i The UI incorporates a number of features designed to facilitate information retrieval while also supporting information visualization. It is designed after the Windows Explorer interface: two panels with the left panel being a navigation view and the right panel being a detailed display view. Selections in the navigation view change the contents of the display view. A high-level screenshot of Venice is shown in figure 3. A close-up of the major Venice components is shown in figure. The navigation view holds one of several different representations for navigating the s. A row of buttons at the top of the navigation view select the type of navigation. Currently there are only two views implemented: the inbox navigation that causes all s to be displayed in the display view, and the topic view. The inbox navigation view provides a more traditional view of the s in a linear inbox. Figure 3 : Venice Screenshot The topic navigation view contains buttons that select the different attributes on the s. Each button has three states: Off: the topic does not select any attributes; On: all s with that attribute are selected; Not: all s without that attribute are selected. The intersection of the sets of selected s of all of the topic buttons is the set of s that is displayed in the display view. For instance, turning on the topic buttons Meeting and Monday will select those s that have both the meeting and Monday attributes. This is how one would look for a particular about a meeting that was held on a Monday. The date also refers to when the was sent so the display list would also contain s about meetings that were ed on Monday. The interactions of the buttons in the topic navigation view create a simple visual query on the attributes of the s. Without a dialog box and without typing, a user can do a simple boolean query on the attributes and instantly see the result in the display view. Some of the buttons in the topic navigation view are customized to do special types of selections. For instance, the date button displays a slider that can easily select a date range one slider selects the beginning date and another selects the ending date. Creating a date range and then turning on the date button will select all those s in that date range. 5

6 Future topic buttons will perform more complex selections of attributes and relationships of attributes. One proposed button performs a like this operation. Using the vector similarity information, a user could select one or more nesses in the display view and then turn on Like This. The like this topic would select all s that were like the s selected in the display view. In the future, new navigation views will be developed to make different selection and searching easy graphical or point-an-click operations. Views showing a 2D or 3D view of s and attributes have been proposed and will be incorporated. The display view is modeled after the Outlook list. Each is a line and each line contains the s date, from, subject and flags showing read, attachment, etc. This creates an easily scanned list of the s that were selected by the navigation view. Following the standard Windows conventions, any of the columns can be sorted in ascending or descending order and s can be selected via single clicking. Although not a main part of the Venice research, the UI is being used to test some ideas of using the graphical ability of the PC to display more information about the s. For instance, the face of the topic navigation buttons displays a histogram of the s in that topic. The horizontal axis is time and the vertical axis is the number of s. So, the button also displays time and frequency information about the s as they relate to the topic. The UI has also attempted to tie the navigation and display views together by having the interaction not be one way. Normally in Windows programs, changing things in the navigation view would display new information in the display view while changing things in the display view does not effect the navigation view. In Venice, selecting s in the display view causes the histograms displayed one the topic buttons to change color where that occurs. This gives the user a clue of which topics the belongs to without overburdening the interface with new dialogs or panels. The s are composed, read, and replied to using the Outlook OLE objects. If a is double clicked in the display view, the s ID is used to create an Outlook display object. The Outlook objects use to fetch the body of the and handle attachments and the other operations associated with reading and composing . Results As of the writing of this paper, Venice is finishing its development and will begin alpha test soon. The testing will be on several people within Intel to see if users of will find this type of information management useful. Future Work The initial version of Venice is addressing the management of an individual s database. The searching for an is based on its attributes rather then its name or location. Future work will be to generalize this concept to all the information in one s computer. For instance, document editors can have Remember and Recall menu items in place of Save and Open. To keep a document, a user just selects Remember. To load that document later, the Recall menu item would pop up a navigation dialog box which would present several different ways of looking at the attributes of document so you could look for the document by when it was created or what it was about or who it mentioned. The goal is to use the processing power of the desktop computer to manage (store, find, organize) one s information thus unloading the user of a menial task that is better done by the computer Conclusion The goal of the Venice project is to address the overload problem through an information management and user-interface perspective. The system indexes for the user by content, graphically presents the information, and supports visual querying to retrieve the desired s. Venice is currently in the prototype stage. To determine if Venice meets its objectives, we intend to deploy a prototype of the system in Q3 of 997 and conduct usability tests. Results will include usage and feature statistics, user feedback on what aspects of Venice are useful, and areas for improvement and future work. References [] Gwynne, S. and Dickerson, J. Lost In The . Time Magazine, April 2, 997. [2] De la Cruz, I. And Thaler, L. Inside Mapi. Microsoft Press, Redmond, WA [3] Karlgern, J. and Straszheim, T. Stylistic Variation in an Information Retrieval Experiment. Tech Report, NYU,

7 [4] Lehnert, W. and Riloff, E. Information Extraction as a Basis for High-Precision Text Classification. ACM Transactions on Information Systems, 994. [5] Paice, C. Automatic Generation and Evaluation of Back-of Book Indexes. Prospects for Intelligent Retrieval, Informatics 0, Cambridge England, 989. [6] Pazzani, M. Syskill and Webert. Proceedings of the 996 Conference of the American Association of Artificial Intelligence. Portland, Oregon. AAAI Press, 997. [7] Quinlan, J.R. Induction of decision trees. Machine Learning,, 8-06,