I've been thinking a lot and writing code to experiment with a Folksonomy module. The long term goal is a parallel to Taxonomy that can be used alongside or instead of Taxonomy. It would provide a free form text field(s) on nodes that let the user enter comma-separated keyword tags in a del.ico.us style. There are two use cases for this. 1) General classification and navigation of internal Drupal objects. Presumably this means exclusively nodes. 2) Various group classifications of external objects to duplicate del.icio.us functionality for a Drupal site's community. I think, but I'm not sure that this is exactly the same as 1) There are a number of key ideas taken from current folksonomy projects on the web. These tend to be database intensive. - Using clustering analysis to derive "popular" tags. - Similarly to derive "related" tags. - Navigation via an information block about the current tag page containing; search; my tags; popular tags; tags related to this one. - Faceted search to drill down on multiple parameters. - Innovative data entry support. eg; one click adding of existing tags from a list; Google Suggest style on the fly updating of suggested tags based on what's been entered so far. There's also quite a lot of knotty questions around things like access rights. - Should only the author be able to add tags to a node? - Can the administrator prune and clean the developing tag vocabulary? - Does it need synonym support? - Does "tag spam" need controlling to stop a user polluting the vocabulary by adding 250 tags to a node? So how to move forwards with this? Moshe's folksonomy module is currently really just a placeholder (no offence Moshe!). I think there's an assumption in there that a node would only have a single tag from a particular Realm (folksonomy->realm ~= taxonomy-vocabulary). This doesn't look right to me. I would expect most nodes to have 2 or 3 and perhaps 10 tags from a realm. I've found it impossible to add the next iteration to Moshe's code without at least doubling the amount of code and reworking the database table(s). The next step is a biggish one. The Taxonomy on the fly module really isn't the same. The key bit of del.icio.us style tagging is the free form entry of multiple keywords. There should be no onus on the user to force them to select from a list and create new entries in the list if one's missing. It should just happen. Some of the parallels with taxonomy mean that you end up cutting, pasting and reworking large amounts of Taxonomy code. And because Taxonomy has been around for a long time there's quite a few places where Taxonomy is treated as core and modules have specific support for it. Which is not a problem except that a folksonomy module would want to be similarly treated as special. Which suggests that perhaps Folksonomy should be a development of Taxonomy. Perhaps there's a new vocabulary type "folks" which has free form tags instead of a tree. Working against that is that it's sufficiently different that a lot of Taxonomy code would have to be duplicated anyway. I also think this is too unformed yet and so at least to start with it should be done in the sandbox of a contributed module. Maybe later it can be merged into Taxonomy. So anyway, my second attempt at this is much more Drupal style and extends folksonomy.module. But it extends it enough and makes enough new assumptions that I really need to talk about this before careering off into left field. ps. The hidden agenda in all this is a tag based Craigslist clone built in Drupal. But that's another story. ;-) -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/