[drupal-devel] A Folksonomy module

[Julian Bond]

"Taxonomy won't work well with 1000 tags". "Taxonomy needs too much work 
to support folksonomy modules.". "Use system vocabs"
I looked at this page /admin/taxonomy and some of the Taxo edit controls 
and couldn't see it working with very large numbers of terms. I think 
*all* the user interface for a tag vocabulary would need reworking. So 
it's hard to see what actually gets reused. The form control for use on 
nodes is going to be different so preview form would need a hook. 
Although some Taxo functions for saving and loading could be re-used, 
the output from a free form tag entry will need converting before it 
fits into the Taxo scheme. So yes, it would be possible to use the 
vocabulary and vocabulary_node_types tables (at least I haven't yet 
needed to extend them) but taxonomy admin couldn't show them usefully 
and almost none of the vocab manipulation code can be used as is. So 
what's the point?

However, Moshe's last post convinces me I need to go and look at 4.6 
forum and prove to myself again that Realm can't use the vocabulary 
table and there's nothing in taxonomy that can be used as is.

Data model.
I don't believe that users own their tags. I think they only use tags on 
specific data. So "My Tags" means "The Tags I've used". In which case 
either node_tag has a uid field or we derive it from node.author.

There's a fundamental choice that affects everything else. And it all 
depends on if you think a tag exists independent of the nodes or other 
objects it's attached to. Or that tags only exist

1) Independent tag
Realm table; rid, name
Realm_type table; rid, type
Tag table; tid, rid, name optionally add cached data like count
node_tag table; nid, tid  Optionally rid to make queries faster and 
reduce joins.

2) Dependent tags
Realm table; rid, name
Realm_type table; rid, type
node_tag table; nid, rid, name

1) Is more normalised. It will make adding tag_tag synonym and related 
tables easier to build later. It makes admin editing a tag easier. It 
needs more joins. The saving process may get slow as each tag has to be 
found or added before the node_tag link can be created.

In 2) most of the queries are easier, faster and use less joins. The 
downside is admin editing a tag is a little harder. Arguably there's 
data duplication; potentially X*Y*Z entries in node_tag where X is 
nodes,Y is tags per node, Z is average tag length. In practice that's 
just not an issue.

Note: All the data model stuff assumes a single link between nodes and 
tags. If you want to do users as well I think there has to be a second 
link table user_tag. Or maybe table_tag_type; id,tid,type but then the 
joins are going to get very nasty.
-- 
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/