Ok, apparently. I'm starting on this "now", even more sooner than before. I've named it folksonomy_shared so as not to interfere with the existing folksonomy.module API by Moshe. I've dubbed it "shared" as it is the key term that distinguishes it from the future direction that Moshe was thinking (per-user-vocabularies). I confess to not really knowing the direction that jbond wants to head in. And, unlike awTags (which, at face value, seems to do most everything I need), folksonomy_shared tries to integrate as tightly as possible with the existing Drupal taxonomy. This gives me the benefit of RSS feeds (an absolute requirement), as well as using synonyms to store similar keywords. * I've started a sandbox for this: sandbox/morbus/folksonomy_shared/ * Only one database change is needed: adding a uid to term_node. http://lists.drupal.org/archives/drupal-devel/2005-03/msg00422.html This morning, I took a look at all the places in taxonomy.module that used term_node, so as to properly handle the new database addition above. At first glance, I don't see /any/ place that requires changing: * The most important thing that distinguishes a folksonomy from a taxonomy ISN'T the I of UI, it's the U. As such, when looking over term_node mentions in taxonomy.module, there were no places that I felt REQUIRED the addition or understanding of the uid. For a "taxonomy" (or, really, a "controlled vocab"), the uid is irrelevant. All normal taxonomies would log the uid as 0, with no change to the existing code. * taxonomy_node_get_terms_by_vocabulary "finds all terms associated to the given node, within one vocabulary." This would seem to be the most immediate and obvious place to include the uid code ("here are all the terms applied to this node, and here are the people who applied them"). But doing so here would be a bad idea: it'd unnecessarily complicate the code (especially when you think about the $key), and ultimately overload the meaning of the function name. Same with the regular _get_terms. * taxonomy_node_save doesn't need to be modified. Without the uid specified, it'll default to 0, which is a proper value for non-folksonomies. folksonomy_shared would save its values with folksonomy_shared_node_save on a nodeapi 'save' hook. * taxonomy_term_count_nodes wouldn't need to be touched, because the number of nodes with a term cares little for uid assignment. * taxonomy_select_nodes would be handled with a folksonomy equivalent version which would allow tids and uids to be passed as params. One of the next usability issues I've been thinking of is URLs, and I've been having some conceptual issues of how to get them right. Your comments will be heartily appreciated. The following are known possibilities: drupal.org/taxonomy/term/34 drupal.org/taxonomy/term/$tid del.icio.us/jagbot del.icio.us/jagbot/origami del.icio.us/origami del.icio.us/$uname del.icio.us/$uname/$term del.icio.us/tag/$term autowitch.org/tags/861 autowitch.org/usertags/1 autowitch.org/tags/$tid autowitch.org/usertags/$uid I heartily agree with jbond: the URL should use $term, not $tid. The problem is that it becomes an either/or situation. Drupal prefers using the $tid (see the first example above), but there's no way to distinguish a $term of "1984" or "666" or "101" from the $tids of the same value. So, using $term is arguably "more" folksonomish, but breaks Drupal tradition. The current format I'm thinking of implementing is as follows: /folksonomy/1 # show all tags in vid 1 /folksonomy/1/term/hello # show all tags in vid 1 for "hello" /folksonomy/1/term/1984 # show all tags in vid 1 for "1984" /folksonomy/term/hello # show all tags in any vid for "hello" # see below for my concerns on this one. The problem with the above is two-fold: * if we want to support multiple folksonomies, the $vid needs to be part of the URL. Otherwise, there'd be no way to distinguish which "hello" from which $vid we'd like to look at. The current taxonomy doesn't do this because we always have the unique $tid. But, if we're going to put $term in the URL, we need a further bit of information to properly assert it. Using the path module would have a similar problem. * if we're using $term and not $vid, why not $vname? As for users, I'm leaning toward: /folksonomy/user/41/1 # show all vid 1 tags for user 41 /folksonomy/user/41/1/term/hello # and so on and so forth. I feel /folksonomy/user/41/1/term/1984 # like these URLs are horrendous. /folksonomy/user/41/term/hello The most immediate problem is, again, the lack of standards. If we're using $term and not $tid, why shouldn't we use $username and not $uid? The URLs become even worse and sometimes broked: /folksonomy/user/morbus/1 /folksonomy/user/rogue_githyanki/1/term/hello /folksonomy/user/killes@www.drop.org/1/term/1984 /folksonomy/user/ohmygodicantdecidemyusername/term/hello Help! This design is the next big hurdle in my head. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus