The development of Drupal Field API obligates us to look at taxonomy.module to keep it relevant and modern. The concerns At Drupalcon DC, Benjamin Melançon (ben-agaric) and Benjamin Doherty (bangpound) began to look at this problem and untie it. Here's what we propose.
Taxonomy.module should primarily contain features for the management of controlled vocabularies: CRUD of vocabularies and terms, describing the hierarchy of terms, and other features that may or may not be fully developed yet: synonymy, term relationships.
A new module called term.module will be the field module that will replace all or most of taxonomy.module's nodeapi functionality. Hopefully it will do more, too.
Field widgets also need some development. Currently, we're using Options.module select widgets, but we shouldn't limit ourselves only to that widget. Tagging autocompletion widget will need to be built.
Tagging features live in taxonomy.module because there had been a significant overlap in the functional, UI and data requirements with taxonomy.module's support for controlled vocabularies. However, this overlap will become much less significant. I'd like to solicit the community's ideas about how to move tagging into a rational place in Drupal 7 and this proposal. We certainly do not propose abandoning tagging at all. We simply need to know where it fits in a Drupal 7 where taxonomy.module lets us manage vocabularies and term.module lets us put terms on things.
Should-be invisible functional changes
Currently, the vocabulary definition contains properties that will need to be expressed in a term field's definition. Without a UI for adding fields to content types, the vocabulary admin form's submit handler needs to call the field functions for creating new fields and field instances. The same choices of multiple values and required translate easily to Field API instance properties.
All the functions in taxonomy.module that load and save term-node relationships are probably going to disappear or be put on a serious diet. All of these data transactions are going to be handled by Field API's own functions or the new term.module's implementation of Field API hook.
These functions are outliers. They work with node-term relationships, but they don't have an analog in the Field API.
Major repercussions of making terms into fields
The current field storage schema is a huge step away from the way term_node table is structured. Most importantly, term_node holds all of these relationships in one table, while Field API defaults to storing field values by bundle. This means that values of term fields of different vocabularies will be stored in separate tables and perhaps even in multiple tables if there are multiple fields made from the same vocabulary.
There's incredible value to easily selecting all nodes with a particular term or all terms for a particular node, so we propose maintaining the term_node table in addition to the Field API storage mechanism. The term_data table would be 100% redundant to the Field API storage table. Dropping term_node entirely would make previously easy tasks much more difficult. This isn't a stubborn commitment to maintaining the term_node table, so please comment if you have some alternatives.
Core dependencies on taxonomy.module
Changes to forum.module will be necessary.
Windows of opportunism
The initial motivation to undertake this project — rather the "final straw" against bangpound's indolence — was Stéphane Corlosquet's proposals for RDFa in Drupal. In this model, nodes are subjects, terms are objects, and dc:subject is the predicate. Currently, nodes and terms are doing something with each other, but we don't really know what they're doing. The RDFa proposal requires us to infer the nature of the relationship, and dc:subject is a safe default. If fields can be made out of terms, we will have better opportunities in core to define the "predicate" or nature of the relationship between nodes (or other things) and terms.
We will also be able to re-use the same vocabulary multiple times on the same thing. Benjamin Melançon gave us an example where nodes describe some aspect of international movement of people or goods. The same vocabulary of geographic place names will need to be used for fields capturing "country of origin" and "country of destination" information.
If user profiles will be comprised of fields, taxonomy terms have a sensible and exciting role to play there.
So far, the patch changes the taxonomy_form_vocabulary form and its submit handler to create fields and instances. We also needed to change one line in options.module to support the new term.module.
No tests yet. I know it's a requirement.