CMT w01: Initial plan for Community Managed Taxonomy

This project, like the rest of my life in general, is dedicated to my father, John Melançon, 1928–2007.

I'm a week [or two] behind on GSOC updates. I'll try to catch up with a couple in the next few days, and then be on report-back schedule every Friday. Less focused data dumps have been and will continue to be posted to Agaric Design Collective's site (desperately in need of an overhaul).

The Community Managed Taxonomy (CMT) vision, to recap, is the option to put taxonomy vocabularies under the control of your site's user community. Huge free tagging vocabularies can become consolidated and even hierarchical without giving up any of the openness of community tags. Categorization of content and even site structure can be put in the hands of users. Instead of trying to imagine in advance what categories ought to exist, or re-filing everything later, you, the admin, can spend your time on more important things, like reading Summer of Code posts about what's on its way for Drupal!

The deliverables:

• A module for adding taxonomy terms on the fly. This means all types of taxonomy terms, not just terms in free tagging vocabularies. This would be useful apart from the democratic, community-managing and should be able to stand on its own. (If this exists, please let me know!) Taxonomy-on-the-fly should itself work in two places: when editing a node and by users with special permissions while simply viewing the node. Note that for hierarchical relationships taxonomy-on-the-fly should be able to create a hierarchy of terms.
• Functionality for eligible users viewing or editing a node to place an existing or a new term for that node where they think it out to go in a taxonomy structure (within a single vocabulary). As above, in a hierarchical vocabulary users should be able to create necessary ancestor terms for placing their term. This is recorded as a vote which others can see and endorse or oppose.
• Functionality for eligible users to add new terms or pair existing terms as synonyms (choosing which they think should be primary, that is, the term that is represented on nodes and in lists and tag clouds). Matching terms as synonyms doesn't necessarily imply an endorsement of position in a hierarchy (if any) so this would be a separate step from placing a new or existing term in a hierarchy. It would be good if both these steps could be shown on the same page, ideally on the node page.
• (Later, and probably built on the new Taxonomy Manager project) Both the above operations should be additionally available from a taxonomy managing page open to the public, so to speak.
• At all points at which terms can be added, the usual ability to provide a description and synonyms should be preserved.
• At a configurable threshold the most popular hierarchical structures and synonym matches become the working structure for that vocabulary. Methinks this part might be a tad harder than I had been anticipating.
• (Maybe) Module for optionally exposing votes for making two terms synonyms (or even parent-child?), but not at the threshold to be reorganized yet, to Drupal taxonomy's core related terms tables.
• (Maybe) Functionality to have synonyms autocomplete when using a free tagging taxonomy (suggested by Fago). One issue here which I want to try to address throughout the module is that a given word can have different meanings in different contexts (agaric the edible mushroom used in cooking and Agaric the open source web development and DJing collective). In hierarchical vocabularies Drupal allows this distinction between terms of identical names (see attached screenshot). As this module tries to make full use of the strength human intelligence has in tagging and categorizing, it would be a shame to contribute to accidental tagging errors of the sort that equating a synonym to a term out of context could cause. Therefore we would want to pull up some additional context (at least the term name) when adding autocomplete for synonyms. Perhaps as an extension of auto-complete, it could display below the entry field any definition and synonyms available for all terms upon, or immediately after, auto-complete.

What will not be delivered:

• This module will not to duplicate functionality of fellow SoC project Taxonomy Manager. It will seek to work with, where necessary supplement, and above all steal functionality from that project.
• This module will not allow users to vote on moving terms from one vocabulary to another. Administrators can use Taxonomy Switch to do that.
• CMT will probably not play well with related terms functionality. Although originally it looked like it might be a good fit, Community Managed Taxonomy will really only be able to optionally export its vote data to related terms, but would not be able to do anything with changes made to related terms by an administrator or another module. Thoughts on related terms and their use, actual and potential, for anything (not just CMT) particularly welcomed at this time.
• This module will not make tea nor biscuits.

What may or may not occur:

• This module might, or very well might not, unleash the creative power of we the masses to engage in the art of taxonomy in little bits as time permits, resulting in categorization so useful to people that the meaning of life, the universe, and everything becomes clear. Or at least we see our common desires and understandings and organize our collective resources to overthrow illegitimate power structures around the world. Again, absolutely no guarantees on these points; it's all quite beyond the technical specifications!