User Interface
On any CMT-eligible node page, you have three operations.
The first, add term, applies to the node itself, and so can always be present.
The second and third apply to terms, and so have to have a user interface for each term a node has (if any).
Each operation can stand alone, but the latter operations can also be seen as subtasks of the above.
term[s] node | | | | | |_> add new or existing term | |______L_> position term |_L______L_> add new or existing synonym and flag which gets naming rights
Add new or existing term includes adding or seeing, respectively, description and suggested synonyms.
Position term applies to hierarchical vocabularies only.
The UI is going to be hard and pretty AJAX dependent for a reasonable user experience.
Both "add term" and "synonymize" (this word should not appear in the UI!) will save space by having the add new term functionality use the same (autocomplete) field as add existing term.
Separate actions. Not necessarily do you mean a term should be moved to where the term you pick to be its synonym is.
This example is for a term named tag (slightly confusing, now that I think of it).
Tag
Position
Parent(s)
commerce > sale - endorse / oppose
ordering system > alphabetical > T-word - endorse / oppose
Suggested parents
<root> of Vocabulary - endorse / oppose
pasta - endorse / oppose
Add parent [_____________]
Synonyms
Existing synonyms
label - endorse / oppose
Suggested synonyms
Term Auto Group - endorse / oppose / make term name
Add synonym [__________] [ ] make term name
In the case of a single hierarchy, "Add parent" would say "Change parent" and (maybe) would automatically count as a vote against other existing and suggested parents.
Endorse functionality is a key part. It gives you the same vote as someone else, data-wise, without having to go through the same steps.
People ought to be able to vote to make synonyms real terms, or perhaps the "make this the term name" functionality together with the ability to add new terms or edit existing term descriptions is plenty. This functionality will not be implemented for now.
Possibility of confusion between adding a term and adding a synonym. I really did want this to be more of a spectrum, so maybe the confusion is just mine.
It would be really, really - um - interesting to let people 'recursively' edit terms-- edit a parent term from this page, for instance. Maybe its crazy, but I see all action taking place on the node pages as easiest and most inviting for the user.
This should all be invisible (or not even loaded) until the user presses "edit" next to a term name, or add term. This all falls under the body of the node text (or I guess wherever the taxonomy is located? No, even for themes that stick terms in a small space in the upper left of a node or something, for CMT-eligible users they should be able to see and edit in a nice open space below the node).
Data model
Data wise, add term uses the same structure as the default taxonomy term_data table plus a row tied to Voting API. (Term name is an exception.)
Position term also duplicates taxonomy's way of doing things, but with a unique ID for voting API to hook into and track. (UIDs are stored by Voting API.)
In short, Community Managed Taxonomy (CMT) should be making the following tables. Vapi_id stands for Voting API ID and should probably be changed to something that doesn't have a tendency to get shortened to vapid.
cmt_term_data
vapi_id
tid
description
weight
LEFT OUT: vid (for now, cannot vote on what vocabulary a term belongs in)
name (inserted into synonym table instead, where votes for names are tracked)
cmt_term_hierarchy
vapi_id
tid
parent
cmt_term_node
vapi_id
nid
tid
cmt_term_name (based on term_synonym table)
vapi_id
tid
name
cmt_term_name is actually called twice from Voting API. In one incarnation people are voting on what synonym names a term ID should have.
Then we add another voting API pointing to cmt_term_name for when someone votes a name should be made primary (which is the case automatically when a user submits a new term, which is why name is left out of cmt_term_data so it can be tracked here).
Therefore, when you vote for a term to exist you are also voting for at least one entry in the cmt_term_name table. It's not really associated with anything except your proposed term, though... hmmm.
Questions-of-the-moment
Voting API ID as a hash of other values in a row?
Should vapi_id be a unique hash of what else is in the table? Or should we just check in a normal way if a vote for a given organization of information has been cast? And/or use a multi-column unique index? Any performance, reliability implications?
Vote on term relations?
We can let people vote on term relations directly also, or we can have the option to derive term relations from synonym suggestions.
I lean toward the former (which would add a cmt_term_relation table with vapi_id, tid1, and tid2), but I think I'll have to come up with a clever way to condense the information available to vote on and derive the information for these tables, or it's just too overwhelming.
For instance, synonyms and related terms could theoretically be derived from terms suggested on the same node. But I don't like this approach; the point of CMT is to enable lots of people to contribute with their intelligence, not to try to create a hybrid form of artificial intelligence.
But it's just too confusing to ask people to vote on term names, synonyms, and related terms. Proposed related terms could double-count as synonym votes.
Need to take another step back and approach this from a users perspective, with a better test case / test data.
More:
- Agaric's project discussion page: http://agaricdesign.com/project/community-managed-taxonomy
- Drupal.org project: http://drupal.org/project/cmt
- Community Managed Taxonomy posts are tagged CMT