Morbus Iff <morbus@disobey.com> Sun, 6 Mar 2005 11:35:23
- 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.
The trick is clearly to get down to a small enough subset (say 30-50). Some approaches. - top 30 of my tags - top 30 all tags - top 30 tags related to the tags already there. This obviously works best in edit rather than add. The google suggest approach would be to have a 30 most likely in a box below the field and have that box update as the user types in entries. nutr.icio.us and the latest del.icio.us bookmarklet give guidance here. This is icing on the cake, but something to drive convergence and consistent tagging is important.
- Should only the author be able to add tags to a node? Perhaps append only, but that's just a different type of war.
In a wiki style, this would make complete sense. But then you need history. Otherwise you get into either flickr style "only my friends can change the tags on my nodes" or author tags and viewer tags with different weight for each. Either way this is icing and can be ignored for the moment. Just Author and Administrator is fine.
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.
I'm undecided about the data model. One option is a node_tag table and that's it. node_tag:nid, uid, tag. this isn't normalised but it makes the queries simple and fast. Add count and related fields and almost all the access routes become really simple at the cost of calculation time of count and related during inserts, updates and deletes. The normalised approach is tag: tid, tag, count; node_tag:nid,tid,uid; tag_tag: tid1, tid2 Easier updates, more joins, roughly the same calculation. Remove that uid and rely on node:uid and you have almost the same thing for another join. Arguably tags only exist in relation to nodes and not on their own. So "My tags" means "Tags I've used on nodes".
- 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.
From a development POV, this makes it hard to do purely as an external module. -- 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/