Frankly, I’ve struggled to find a good personal use of TaQuilla for use in my dogfooding. I’ve tried using it to categorize “interesting” posts, but I can’t even agree myself from day-to-day what is “interesting”, and the soft tagging is even more indecisive. But I’ve finally hit on a good use for it in my workflow – rejecting of sports articles in newsfeeds!

I have an RSS feed that subscribes to local news for the “Seattle Times” newspaper, but I find a lot of the articles are sports related. Now I am a certified geek, and not really interested in those types of articles. So what I did is to create a tag “Sports”, then I setup TaQuilla soft tags for “Sports” on the RSS feed, create a virtual folder that filters out articles tagged with “Sports”, and voila I can read the newspaper feed without all of those annoying sports articles. It’s particularly useful since many of the same articles get updated multiple times, and the updates are very efficiently rejected with the bayes filter if I tag the original.

(All references to extensions in this posting refer to the 1.0.0 versions, which as of this writing have not been posted to AMO yet. But they should be available in a few weeks.)

Implemented UI

Briefly, inherited properties are a property that can be defined globally, at the server, or at the folder, and its characteristics will be propagated to child objects. This make it easy to specify precisely how the property is applied.

As an example, I have recently implemented a feature “Index in Global Database” in GlodaQuilla which can be used to selectively suppress certain accounts or folders from being accessed by the global database indexer. In the account manager, where indexing can be disabled for an entire account, the UI looks like this:

Each inherited property has default values which are typically set by the base code. In the case of the gloda database indexer, everything but newgroups are indexed by default. Initially each inherited property is set to just use the standard default processing, but if I clear the “default” checkbox, then I can turn off gloda indexing for this account.

If I do that, then go to a first-level folder in the account, I see the following under folder properties:

At the folder level, because I disabled global indexing on the account, it is now shown as disabled on the folder. I could clear the inherit box and selectively enable it on just this folder and its children if I wanted.

This particular UI merges naturally with the existing methods of setting properties in mailnews, but I’m not sure it is optimum for an inherited property. The inherited nature could be more clearly shown, and a particular feature more quickly configured, if I showed a tree of accounts and folders, with checkboxes next to each account to enable or inherit the feature. Maybe in a future version.

Implemented properties

Here are some of the implementations of inherited properties that exist in my extensions:

1. (GlodaQuilla) Index in Global Database – suppresses the running of the global database indexer
2. (FiltaQuilla) Apply Filters to Folder – for Imap folders, allow incoming filters to run on that folder
3. (JunQuilla) Analyze Junk – allow junk processing to be turned on or off. This also allows junk processing to run on RSS or news folders.
4. (TaQuilla) Analyze particular automatic tags.

Issue: Existing mechanisms

Ideally, the inherited property would be the one and only way to manage a program feature. But for existing features, the existing mechanisms remain, which can lead to possible confusion. For example, with JunQuilla’s “Analyze Junk” property, there is existing UI to enable junk processing at the account level. Here the inherited property will always override the default mechanism (but that is mostly because I implemented it in core that way, and I have a little influence on how junk processing is handled in core.) For GlodaQuilla’s “Index in Global Database” the behaviour is different. Existing UI will only allow this to be enabled or disabled globally, and the inherited property does not override this. The inherited property code uses the default server preference as a global enable/disable for a property, so if gloda used that same mechanism instead of an independent preference, this issue would go away. I guess I could say the same thing about junk processing as well.

For FiltaQuilla’s “Apply Filters to Folder”, there is a subtle issue in the inherited nature. I did not implement in core the ability of the inherited property to override the existing default as applied to the Inbox, so incoming filters always run on the inbox. That creates 2 ui issues. First, although I show at the account level the “Apply Filters” option, it does not actually suppress application to the inbox as one would expect. Second, I currently do not show a folder property for “Apply Filters to Folder” for the IMAP inbox since it would not make sense there, so that also means there is no way to enable processing of filters for the children of the inbox. Maybe I should call this feature instead “Apply Filters to non-Inbox Folders” to solve this, or change the core code so that the feature also applied to the Inbox.

Issue: My RDF-inspired property for junk management

Looking ahead to a world where a number of extensions might try to define bayes filter traits, in code I recommended that properties used to manage junk processing use an RDF-inspired globally unique identifier. Then I followed my own advice and defined the identifier that controls junk processing on a folder as: “dobayes.mailnews@mozilla.org#junk” Unfortunately, the existing account manager code does not allow periods in property names, which means I could not use the account manager to manage this. I’ve filed bug 525024 on this issue, and perhaps that can be incorporated after TB 3.0 / SM 2.0.

Issue: Missing inheritance levels

I’ve heard others comment that often they want to set a property on a particular class of folders, say on all Trash folders, or all Sent folders. I’ve considered implementing another level in the inherited properties feature, that would be a folder type. So you would then set a property that would be inherited by any folder of a particular type, and its children – and of course also overridden by the local folder property.

Issue: UI for global property

All of the inherited properties could also be enabled globally using the “mail.server.default.<property>” preference, but I did not give any UI for that in my extensions. I thought that would be too confusing for the user to show those preferences, which would be very similar to existing mechanisms. This is not an issue for properties that use the preference system for server-level issues, but none of the existing server-level preferences are also inherited properties. Perhaps we could move that direction in the future.

Major changes are planned for FiltaQuilla (new custom searches) and ToneQuilla (switching to ogg Vorbis as the standard format). JunQuilla should have bug fixes, TaQuilla and GlodaQuilla will be virtually unchanged.

The bayesian classifier that is part of the Thunderbird and Seamonkey distributions has been generalized by me over the last few months to allow it to be used for such categorizations, rather than be limited to spam recognition as originally implemented.  I can demonstrate its use with my TaQuilla extension, which allows automatic tagging of message items using the bayesian classifier. The release available on AMO works with Thunderbird 3 beta 2, but only supports email messages, not RSS feeds. I am extending the mailnews backend in bug 471833 to also apply bayesian filters to RSS messages. My private patch now does that, so I thought I would demonstrate how it works.

I’ll use my Planet Mozilla feed items from Thunderbird, and apply the tag “Interesting” to posts I want to read. First, I need to do a little training to show the bayes classifier what is Interesting and Not Interesting. So I picked posts from two people and flagged them as Interesting, and two others as Not Interesting. (Note this is a demonstration only, no disrespect is meant to the poor saps whose posts I’m calling Not Interesting here!) For Interesting, I chose posts from Mitchell Baker, and the Rumbling Edge posts from Gary Kwong. For Not Interesting, I chose the Mozilla Community meeting note posts from bsmedberg, and the European Community marketing efforts posts from William Quiviger. I picked two from each author to train, for a total of eight trained posts. After training, I reran the bayes filter on the folder to see how effective it was in categorizing posts similar to those that I had trained.

So, how did we do with this minimal amount of training?

The bayes filter determines a score of 0 – 100 for each post, with 100 for posts that most closely match the category, and 0 for those that most poorly match.

For the Rumbling Edge posts, I had 7 total in my sample, and used 2 for training. For the remaining 5 untrained posts, 4 had a score of 100 showing a strong match, while 1 had a score of 84. Looking at that post, it was quite different from the others, which were mostly lists of fixed bugs.

For the Mitchell Baker posts, of the 5 untrained posts, 4 had scores of 90 -100, and one had a score of 49, which is indeterminate. So close, but not perfect.

The quality of the match was similar for the “Not Interesting” posts, though of course here our goal is a score of 0 instead of a score of 100. For William Quiviger’s posts, the 7 untrained posts had scores of 0 or 1. For bsmedberg’s Meeting Notes posts, all but 1 of 19 untrained posts had scores of 0, and one had a score of 9.

So overall, this is pretty good categorization with minimal training. In the future, all new posts that arrive will be automatically categorized, with posts having a score of >50 tagged as Interesting, and < 50 untagged. If I am unhappy with the tagging, I can train additional messages by simply applying or removing the tag from the incorrectly categorized post (which is a single keystroke in Thunderbird.) To display posts that I want to read, I can setup a saved search folder that shows only Unread Interesting posts, and sort that by the percent match.

When I do this, and apply it to all 578 posts that I currently have in my Planet Mozilla folder, here’s what I get for the top 17 posts:

So I see all but 1 of the Rumbling Edge posts, and all but 1 of the Mitchell Baker posts.

What about the other Interesting posts? The Burning Edge and Seamonkey posts are very similar in intent to the Rumbling Edge posts, so it is understandable that they are also rated as interesting. Daniel Glazman’s post mentions “messages”, “Thunderbird”, and “mail” so it is also understandable. The Aza Raskin hit seems more random, the matched tokens are common words like “how” and “they” which would get averaged away with more training.

So overall, I think this will be a useful tool to add to Thunderbird to assist users with sorting of massive planet-style feed aggregations. I expect that the features demonstrated here will be available beginning with Thunderbird 3 beta 3 (in late April) when the TaQuilla extension is loaded.

Bayesian filters need training, and this is provided in the background for you as you tag or untag messages. Once you “prime the pump” by tagging some messages, and untagging a few others, then it just works. There are also some diagnostic displays available, that show the message tokens that were used to arrive at a message tagging classification, or will show in the message pane the percent match of messages to a soft tag.

I’ve been testing this using a tag “Personal” that I apply to emails that are not associated with my business activities. I have a variety of personal interests, and a variety of business interests, so trying to devise a message filter to separate them would be quite challenging. But TaQuilla is quite effective at separating the two. Then I have a “Personal” and a “Not Personal” virtual folder, so that I can view messages of the appropriate nature depending on whether I am working or not.

To give you some idea how it works, here are tokens used to classify a few messages that I recently received. The first was a weekly general mailing from my church’s pastor, classified as Personal. Here’s the analysis:

TaQuilla Analysis of a church email

This is the detail view of a message from TaQuilla. The “Token” column shows words from the message that participated in the analysis. “Token %” is the probability that a message containing that token should be tagged as Personal. The “Running %” column is the total percent match of the message, as a running total starting with the strongest tokens.

The 99% at the bottom of the “Running %” column shows a very high match to Personal. Words like “pastor”, “worship”, “Sunday” strongly matched Personal, so it was automatically tagged Personal.

A second example email was a posting on the thunderbird-testing list, that was not tagged as personal. Its analysis is:

TaQuilla analysis of a Thunderbird-related email

Here you have words like “Feedback”, “bug”, and “Thunderbird” which are strongly not-Personal.

And finally, we have a strange one – a message from my son asking a question about spam processing. What did Taquilla do with this?

Taquilla analysis of a mixed email

Well it could not decide. The percent match was 51%, which was marked as Personal because the cutoff is 50%, but it’s pretty clear that this is a confused email.

At present, soft tagging only supports email, and it is either on or off for the entire application. By the time Thunderbird 3 beta 3 is available, I expect to have enough hooks in the backend code to also support RSS feeds and News, as well as provide more granularity on which accounts and folders have soft tags applied. I’m hoping that I can use soft tagging in large-volume lists such as Planet Mozilla, to automatically flag posts that are “Interesting”. (I’ll incidently provide junk management for RSS and news in the same patches.)

ToneQuilla

The published version has a bug that interrupts the playing in some cases. I’ll fix that, but otherwise no changes. Prior to TB3 though I would like to implement support for Ogg Vorbis files in TB core, and add that to ToneQuilla as well. I’ll try to add some more tones at the same time – though possibly in a separate extension so that the main download does not get bloated.

JunQuilla

Changes in the backend to the database interface have made portions of JunQuilla quit working with recent Thunderbird builds. I’ll fix that. Also, I will be able to add the junk detail views shown in my recent post since the required backend code has now landed. There’s also a small error that appears in the console on startup that I hope to find and eliminate.

There will also be a bug fix in beta2 in the backend bayes filter code that could make a big difference in the effectiveness of the filter. Previously, the mozilla-added header that indicated whether a message was read or unread was used as a bayes token. But that makes no sense, since marking as read is a post-receipt action, all incoming messages are unread. So depending on how you trained your messages, there could be an unexpected biasing of unread messages either toward good or junk. In my case, unread messages were biased toward good, tending to lower the junk score by about 7 percentage points – which is a lot.

FiltaQuilla

As with JunQuilla, some functions quit working in recent builds (at least Do Not Notify, possibly others). I’ll need to fix those. I don’t know yet if I will have time to add additional requested features. I see that the Penelope team (Mozilla-based Eudora client) is hoping to add the detach attachments action to the core, so I probably will not do that here. I’ll try to get a preliminary version of the nsIProcess interface up so that you could launch a program with parameters.

TaQuilla

The backend changes that I needed to allow this to work have now landed, so I should be able to release a preliminary version of this soft tagging extension.

Soft tags are enabled in a setup screen that lists all of my tags, whether they are enabled, and also whether I want to show diagnostic and status columns in the thread pane.

Checking “Status Column” shows soft-tagging status for each message in the thread pane, which can either be either hard-tagged (showing as a check) or soft-tagged (showing as a sigma). Checking “Percent Column” shows a numerical column in the thread pane, which is the percent match of the message to the tag as determined by the bayes filter. “Enabled” determines whether the soft-tagging calculations are done for the particular tag. The numerical percent is the setpoint in the bayes calculation for deciding whether to apply the soft tag or not. So far, I have always just used 50 as the setpoint.

In addition to the options, I added commands to calculate soft tags on selections and folders, similar to the junkCommands.js routines for junk management.

I’m beginning to believe though that applying soft tagging is going to be as simple as saying “yes” to enable it for a particular tag. So I’ll probably extend all of the tag definition dialogs with an “enable soft tags” column, and reserve the more detailed setup to TaQuilla Options.

So at this point, I am happy with the basic operation. But a number of issues remain, many dealing with the backend of the mozilla mailnews code.

1. I am relying on database listeners in the code to detect changes to the message that determine whether I need soft tag a new message, or train the bayes filter when the user manually tags a message. Although this mostly works, it is fairly inefficient. Also the listeners are not fired reliably in the backend code. I may need to add back-end events that are specific to tag and trait management to increase efficiency and reliability.
2. The bayes tokenizer currently sees the applied keyword as a token to include in its calculation, which leads to some strange feedback effects. (See bug 472005) I have a patch for that now to allow extensions to selectively enable and disable including specific headers in the bayes calculations.
3. The bayes calculation currently returns 50% until training is done both on emails that match a trait, as well as those that do not match a trait. This makes it more difficult to start up the soft tagging. I have a patch I’m using that returns 100% if only emails that match the trait are trained. This makes it easier to implement a simple user interface for soft tags, so that users merely have to enable soft tagging for a particular tag, tag at least one message, then correct any errors that occur in the future. Without this patch, you need to convince the user to manually mark some messages as NOT matching a trait, which is counter-intuitive and difficult to explain.
4. As I try to use tags in multiple dimensions (that is, one dimension for status, and another for category) the limitations of the existing tagging interface in TB become more apparent. I can fix that in an extension though. As a start, I will probably add a column that shows applied tags – but only using the first character of the tags to save space.

One of the more interesting applications of soft tagging would be to automatically categorize interesting blogs, to assist the reader in knowing which blogs to read. This would be particularly interesting in a “planet” style of aggregated blog. Although currently the mailnews backend does not apply bayesian calculations to feeds, I investigated this some and believe I could add that through an extension. I’ll probably do that as part of TaQuilla eventually.

I enabled soft tags on a “Personal” tag, to track emails that are associated with my personal life. I trained about 10 emails – a few from a current thread with my family, a message from my church, and a Netflix notice. I picked also a few bugmails and trained them as not personal. Then I applied the soft tags to another 20 emails – and it correctly decided when to apply the Personal tag to all of them! I have no idea what information it is using to do this, though I suspect it is just the names of the family members. But it is quite exciting that it works!

Unfortunately I had to apply a post-TB beta1 patch for this to work, so TaQuilla will not be able to work with beta1. My goals right now are to continue to figure out which hooks I will need in the base code so that TaQuilla will work well, and try to get them all in before beta2.

One interesting observation is that the training of the bayesian filter, which is a major pain to maintain for the case of junk mail, is much easier with soft tags. The reason is simple. For junk mail, the goal is to put junk messages into a “junk” folder, which ideally you never look at. For that reason, it is critical to have a very low chance of falsely classifying a message as junk. But for soft tags, you can accept a few false positives. So we can do the training for messages that match the category “Personal”  (which I call the pro trait) when you simply tag the message. I can then train messages that do not match the tag (which I call the anti trait) when you untag a message that was falsely tagged by the algorithm. This is very simple and unobtrusive. What a difference it makes to accept a few false positives!