I've been thinking a lot and writing code to experiment with a
Hey Julian. Nice to see you again. Been a few years, eh? Within a month or so, I'll be working on converting a homebrew site to Drupal, and they've got about 7000 terms in a similar-enough-to-be-a-folksonomy situation. I've recently discussed this on the list, including a) the GUI they're used to using, b) the workflow they expect, and c) the "here are some better tags" UI and code. Unfortunately, the list archives are not updating as frequently as normal so, if you'd like copies, lemme know and I'll forward them on. For now, an example of c): http://www.disobey.com/detergent/2005/similar_keywords.jpg
- Innovative data entry support. eg; one click adding of existing tags from a list; Google Suggest style on the fly updating of suggested tags
From my standpoint, "one click adding of existing tags" would be impossible - 7000 terms creates a rather disasterous selectbox, and even something like "top 50 terms that have used the most" creates such a small subset of the whole as to be unuseful.
- Should only the author be able to add tags to a node?
This should be a per-site preference, IMO, but ultimately devolves into why /I/ personally despise folksonomies: my "funny" is not yours, my "sexy" is your "disgusting", and your "rock" is my "crap". I'd never allow someone to change my tags, solely for this reason. Perhaps append only, but that's just a different type of war.
- Can the administrator prune and clean the developing tag vocabulary?
An administrator should be able to do everything, yes, and that permission should be grantable to other users via access privs.
- Does it need synonym support?
My envisioning of folksonomy support within Drupal is tightly keyed into the existing taxonomy stuff. Likewise, my need for the "similar" code (in the URL above) prompted a great idea from killes: if a user chooses a better keyword, then their original choice becomes a synonym of their new choice. This automatic synonym linkage will help limit the number of tags, as well as satisfy your "related tags" feature request. Largely, my vision of folksonomy support in Drupal: * user creates a taxonomy via the normal means. * user flags taxonomy as a "folksonomy". * user flags which node types to apply the "folksonomy" to. * a "folksonomy" input box is appended to selected node types. * user types tags in comma-spliced format. * upon submission of the node form: * each tag is checked against taxonomy flagged as "folksonomy" * new tags are added automatically, and user id gets "created" status. * tags are applied to nodes (via normal taxonomy) and user (new table) * after submission of the node form: * optional "improve your tags" code comes up (see UI URL above). * re-chosen tags becomes synonyms of master tag. * re-chosen created tags are then deleted. The above uses the existing taxonomy support, and seems to only require one additional table to remember what user is creating what term: tid | uid | created ------------------- 3 | 12 | 0 4 | 17 | 1 With this, a "My Tags" thing is one or two JOINs away.
- Does "tag spam" need controlling to stop a user polluting the vocabulary by adding 250 tags to a node?
Sure. Default to 10?
be similarly treated as special. Which suggests that perhaps Folksonomy should be a development of Taxonomy. Perhaps there's a new vocabulary
I agree. -- Morbus Iff ( i've eaten fruity pebbles with p-diddy ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus