Calais? I get e-mail about that at least 12,238 times a day. Buzz off.

No, not Cialis, silly... Calais (pronounced cull-AY). It's a free (as in cost) natural language processing, rich semantic metadata, web service, uh... thingy. The video on the front page is jargon-tastic for those into that sort of thing. But to cut to the chase, it basically reads in text from your site and, based on the bazillions of others sites' text from other people using the service, it figures out some sensible tags for you automatically so your editors don't have to do it.

However, rather than just being a simple flat set of free tags, the tags are instead grouped into areas analogous to Drupal's taxonomy vocabularies which are associated with "Entities" (People, Companies, Cities, etc.), "Facts" (a person's Position or relationships between entities), and "Events" (Sporting, ManagementChange, etc.). The format passed back is in an open, semantic web-compatible format (Resource Description Framework or RDF) which then allows you to form intelligent relationships between articles based on the subject matter. This can be used for things like assisting with SEO, getting better search results, creating an "Other articles like this" block, pulling in external data from other sources that speak RDF, or whatever else you can imagine doing with this kind of information.

How does it work?

To get an idea of how it works, chuck some text at http://viewer.opencalais.com/. For example, here's a Wikinews teaser about President Obama:

It correctly identifies the topic of the article as "Politics," "Washington,United States" as a "City" that the article is about, "Barack Obama" and "George W. Bush" as "Person" entities, and even finds a quotation by George W. Bush (though sadly, not as entertaining as some). Pretty nifty!

So, wanna wire this up with Drupal? Let's find out how!

Introduction

Most people who use forum systems such as vBulletin or PHPBB are used to having lots of extra features that Drupal core's forums don't contain by default, including private messages, smilies, and BBcode. While all of those are available as contributed modules, there are two "must-have" forum features that are a bit trickier, since they deal with access control: private forums, and forum moderators.

Drupal core tends to have an "all or nothing" approach to these issues. Either a particular role can access all content on the site, or they can access none of it. Either a particular role can administer all forums, or they can administer none of them. Luckily, though, Drupal provides a number of hooks so that contributed modules can add in their own robust access handling.

This article will look at three modules that enhance forum privileges, and compare and contrast them: Forum Access, Taxonomy Access Control, and Taxonomy Access Control Lite.

Drupal's taxonomy system is certainly one if its greatest strengths. The ability to categorize, classify, and/or tag nodes is very powerful and theoretically should make it easy to find similar content quickly. But the "finding stuff" part has been a weakness for Drupal. There have been some recent improvements in the core search functionality and Earl Miles' excellent Views module provides a nice user interface to a complex database query engine that can be used in many different ways.

A client recently had me thinking about how to easily "drill down" in taxonomy to find nodes. Taxonomy browser has the right idea, but this module lists all taxonomy terms whether or not any content has been tagged with this term. Views module's "exposed" filters adds the ability to filter by any views-aware criteria such as node-type, author role, and a bunch of other good stuff, but again shows everything whether a filter item "contains" content or not.

Let's use songs as an example -- you're not going to find any results when narrowing down to "Techno" songs by "the Beatles" on the album "Nevermind". So when you select "Techno" you should only see artists and albums with songs in this category.

Of course, Apple has come up with an elegant user interface for this very example:

But how can we adapt this to Drupal? Again, Views' interface comes close and probably makes a great starting spot for non-AJAX backwards compatibility. By setting filters to "exposed" you get a display like this at the top of your page:

And what's more, by combining this with non-exposed filters, you can provide an interface to filter within "song" content items so that you do not need to burden the user with confusing selections like "node type". But Views suffers from the same problem as Taxonomy Browser in that there is no live feedback to let you know that your filtering will yield results.

My thinking is that a little bit of AJAX could really benefit this system. Imagine that as you click on a selection in the left column, the items in the right columns update to show only those containing content. Each column contains an "all" item at the top and multiple selections would be allowed. Well don't just imagine it. Fire up iTunes and use it for yourself. It's so intuitive that it's transparent. It just works.

In terms of the database query logic, each column represent an "AND", while multiple selections in each column represent an "OR". So if your columns are "Genre", "Artist", and "Album", then you would search could look a bit like this: (Genre = "ALL") AND (Artist = "Rolling Stones" OR Artist = "Clap Your Hands Say Yeah") AND (Album = "Their Satanic Majesty's Request" OR "Clap Your Hands Say Yeah"). Of course that's not proper SQL, but the logic is there. It's also important to note that the logic flows from left to right with each column narrowing what shows up in the columns to its right - hence the "drill down" concept. Also note that the logic for hierarchical taxonomy vocabularies would probably need to be handled slightly differently.

Views' exposed filters would need to be prettied up a little bit, but I think most of this is doable using Drupal's core JavaScript functions. It would mostly be a matter of repopulating each select with only items that have nodes assigned to them.

If written correctly, this type of search widget could be a HUGE benefit to Drupal. Add iTunes' real-time search box into the equation and we could really get some respect. But let's just take it one step at a time.