The taxonomy system is one of the great contributions of Drupal to the technology of CMS: the ability to classify content with multiple vocabularies. Each vocabulary represents a dimension of concern in the content being managed. Further, a single taxonomy has a flexible structure: it can be linear, tree-like, even graph-like when multiple parents are chosen. Content can be restricted to be tagged with a single term, or multiple terms can be allowed. Finally, freetagging is supported. That's a powerful tool for the information architect, and indeed it's being used ubiquitously.
But as the complexity of applications built with Drupal rises, so do the demands of programmers with regards to the tools available to them. Thanks to the equally powerful plugin mechanism of Drupal, we count today around 230 third-party modules that enhance the core Taxonomy module. That's a testament to the power of open source as a breeding ground for software, and perhaps even a refutation to those other schools of software engineering which promote up-front, pre-determined and essentially linear design. The core Taxonomy module is itself evolving, incorporating stable patterns found in the community as we'll see later.
I've long been fascinated with classifying information. One of my favorite childhood activities was making lists. In Drupal's taxonomy system I found the seed of the ultimate list-making device, if there is such a thing. As my use of Drupal increased, here are some of the abilities that I've come to need from the taxonomy system:
Classifying nodes with other nodes: think of music albums classified by artist. Each album is a node (i.e., a piece of content) which is related to another type of node, namely the artist. Logically, this means that one of the dimensions of classification of the album is the artist. However, the artist cannot be implemented only as a term in the Drupal Taxonomy sense since it carries much content with it - bio, pictures, etc. It needs to be both a term and a node. This is the duality that modules such as Node Auto Term (NAT), Taxonomy Node and others attempt to unify.
Overriding the default display of a nodes belonging to a term using Views. The default display is impossible to customize without theming, which basically amounts to writing more code. Because Views is the ultimate list-displaying device, it makes sense to use it here, and that's what Taxonomy Views Integrator does.
I've contributed a few minor modules to taxonomy handling, and will no doubt continue to do so in the future. Here are my current attempts:
Bulk taxonomy manipulation: I implemented a simple UI to bulk-assign, remove or exchange node terms. This functionality is packaged as an action, meant to be used as part of my Views Bulk Operations module.
Taxonomy graphing: A module to produce a graph of the current vocabularies of an installation. The graph shows each term as a node, and the way the term relates to other terms and to the root of the taxonomy. This is intended as a documentation tool for a running Drupal system. It is packaged as part of my Graphviz Filter module.