[drupal-devel] A Folksonomy module
morbus at disobey.com
Sun Mar 6 16:35:36 UTC 2005
> 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):
> - 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
Morbus Iff ( i've eaten fruity pebbles with p-diddy )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
More information about the drupal-devel