[drupal-devel] Core Folksonomy: Not Ready for term_node.uid?
Seeing a few more hours left in the day, I started thinking about my proposed change to term_node, which would add a new "uid" column. The argument for it was, in a nutshell: * no duplication of data when the following occurs: * future possibility of "all users can tag any node" Besides the fact that I personally didn't /need/ the feature, I thought it was easy to code in, and provided a lot of future contrib possibilities. Because of this, I fought against questions by jbond and killes regarding "well, can't you just use node.uid to determine 'My Tags'?" I'm now leery on moving forward with this addition. It's a tricky bug, so I'll sum it up here: * administrators should be able to do everything. * administrators will not be able to delete an /individual/ uid's entry in the term_node table. the only solution would be a whole new set of UI screens. The problem isn't the INSERTs or backwards compatibility. Easy as pie. The big problem is that, on node save, the taxonomy code deletes all assigned nid/tids in the term_data, and then recreates them fresh from the incoming $edit data. This is a sensible thing to do - I've used the same trick before. With the addition of the term_node.uid though, it becomes not only "what nid/tids do I delete?", but also "what uid's nid/tids do I delete?". And THAT's the big problem. You are a normal user with node create capability. You add a brand new node, and you add some new terms. Your uid is saved into term_node.uid with these tids. A day later, you go back and edit the node, tweaking the terms. Taxonomy.module deletes all nid/tids matching your uid from term_node. Taxonomy.module resaves your tweaked nid/tids with your uid. So far, no big deal. A uid-aware DELETE would be: DELETE FROM {term_node} WHERE nid = $nid AND uid = $uid; Now, assume for the moment: You are an administrator and you'd like to edit the node. The folksonomy input becomes prefilled with ALL tids assigned. You fix the whatever and you save the node. Hilarity ensues. At first glance, this seems to do the "right thing". Since you're a different uid than the normal user, the _save DELETE will delete all nid/tids associated with your uid (in the previous example, none, as of yet). As the node is saved, brand new nid/tids entries are added associated with your uid. From the perspective of the very first two bullets of this email, Everything Is Perfect: two uids have tagged a node independently of each other. Awesome! But, there are two big issues: * ALL assigned nid/tids are placed in the folksonomy input. * The administrator can not modify another uid's nid/tids. At first glance, the easy answer to the first bullet is "well, instead of getting all nid/tids and showing them, just SELECT based on the current uid". And, yeah, that's a proper answer for a multi-user installation, especially considering that 5000 users could give one nid 5000 unique tids, and that'd make a prefilled input pretty unwieldly. But that fix breaks an important tenet: "an administrator should be able to do everything." There'd be no way, without a new and scalable UI, for the admin to say "Normal user has screwed up, and I'd like to modify his, not my, terms for this node." Conclusion for step #1: node.uid is in, term_node.uid is out. This is still a teensy problem, because an admin could edit someone's node adding new tids, and the "My Tags" feature would be slightly incorrect ("hey! the admin added that tag! not me!"). But, "Tags Associated With Nodes I've Created" just doesn't have the same ring to it. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On Wed, 16 Mar 2005, Morbus Iff wrote:
* future possibility of "all users can tag any node"
Besides the fact that I personally didn't /need/ the feature, I thought it was easy to code in, and provided a lot of future contrib possibilities.
I could use the feature.
It's a tricky bug, so I'll sum it up here:
* administrators should be able to do everything.
* administrators will not be able to delete an /individual/ uid's entry in the term_node table. the only solution would be a whole new set of UI screens.
The problem isn't the INSERTs or backwards compatibility. Easy as pie.
The big problem is that, on node save, the taxonomy code deletes all assigned nid/tids in the term_data, and then recreates them fresh from the incoming $edit data. This is a sensible thing to do - I've used the same trick before.
Well, it is a trick and nothing more. It has bugged many people over time. I suggest to rewrite it to act as follows: - a node it passed, it has a couple of tids attached (or not). - select all the tids that are attached to the node in the DB. - add those tids that were not there before. - remove tids that aren't there anymore. This uses some more db queries, but this is a non-issue since they are only executed on node_save.
With the addition of the term_node.uid though, it becomes not only "what nid/tids do I delete?", but also "what uid's nid/tids do I delete?". And THAT's the big problem.
Not if rewritten as above. I assume that tids are still unique per node. [...]
Now, assume for the moment:
You are an administrator and you'd like to edit the node. The folksonomy input becomes prefilled with ALL tids assigned. You fix the whatever and you save the node. Hilarity ensues.
Not anymore. :) [...]
But, there are two big issues:
* ALL assigned nid/tids are placed in the folksonomy input. * The administrator can not modify another uid's nid/tids.
You can easily make a list of all terms (maybe sorted by user) and a click on the one you want will remove that one (after confirmation). [...] Cheers, Gerhard
I suggest to rewrite it to act as follows:
- a node it passed, it has a couple of tids attached (or not). - select all the tids that are attached to the node in the DB. - add those tids that were not there before. - remove tids that aren't there anymore.
With the addition of the term_node.uid though, it becomes not only "what nid/tids do I delete?", but also "what uid's nid/tids do I delete?". And THAT's the big problem.
Not if rewritten as above. I assume that tids are still unique per node.
tids would be unique per nid per uid: nid | tid | uid ------------------ 17 | 3 | 9 17 | 3 | 12 17 | 4 | 12 and so on.
You can easily make a list of all terms (maybe sorted by user) and a click on the one you want will remove that one (after confirmation).
Where would this screen be? -- Morbus Iff ( i assault your sensibilities! ) 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
On Wed, 16 Mar 2005, Morbus Iff wrote:
I suggest to rewrite it to act as follows:
- a node it passed, it has a couple of tids attached (or not). - select all the tids that are attached to the node in the DB. - add those tids that were not there before. - remove tids that aren't there anymore.
With the addition of the term_node.uid though, it becomes not only "what nid/tids do I delete?", but also "what uid's nid/tids do I delete?". And THAT's the big problem.
Not if rewritten as above. I assume that tids are still unique per node.
tids would be unique per nid per uid:
Hmmm.
nid | tid | uid ------------------ 17 | 3 | 9 17 | 3 | 12 17 | 4 | 12
and so on.
If you insist on adding terms twice (why?), you'll also need to transport the uid info through the editing process. Makes things more complicated.
You can easily make a list of all terms (maybe sorted by user) and a click on the one you want will remove that one (after confirmation).
Where would this screen be?
Maybe on an extra folksonomy tab similar to revisions? Cheers, Gerhard
nid | tid | uid ------------------ 17 | 3 | 9 17 | 3 | 12 17 | 4 | 12
and so on.
If you insist on adding terms twice (why?), you'll also need to transport the uid info through the editing process. Makes things more
What's the alternative? The above layout is the only way I can think that multiple users can assign multiple tids to a node, regardless whether they created it or not. Terms are not being added twice, merely associated twice: you may create a new term "cat" with tid 4, but if I ever use "cat" myself, it'll still be tid 4 only associated with my uid. -- Morbus Iff ( don't heckle the super-villian ) 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
On Thu, 17 Mar 2005, Morbus Iff wrote:
nid | tid | uid ------------------ 17 | 3 | 9 17 | 3 | 12 17 | 4 | 12
and so on.
If you insist on adding terms twice (why?), you'll also need to transport the uid info through the editing process. Makes things more
What's the alternative? The above layout is the only way I can think that multiple users can assign multiple tids to a node, regardless whether they created it or not.
Well, I'd maintain (nid, tid) as unique. I do not see why users should be allowed to assign tags that other users allready assigned to the same node.
Terms are not being added twice, merely associated twice: you may create a new term "cat" with tid 4, but if I ever use "cat" myself, it'll still be tid 4 only associated with my uid.
I am not sure I understand this. Cheers, Gerhard
nid | tid | uid ------------------ 17 | 3 | 9 17 | 3 | 12 17 | 4 | 12
What's the alternative? The above layout is the only way I can think that multiple users can assign multiple tids to a node, regardless whether they created it or not.
Well, I'd maintain (nid, tid) as unique. I do not see why users should be allowed to assign tags that other users allready assigned to the same
Because that's the user-centric way to do it! Imagine a "My Tags" feature. Now, say you and I have very similar ways of thinking. When a node talks about cats, you put in "tuna fish". When a node talks about the phone, you put in "abomination". We've got, for the sake of argument, the following: nid about phones | tid for abomination | uid for killes nid about cats | tid for tuna fish | uid for killes Fine, no problem. When I click on the "Killes' Tags" link, I'll see the above associations, and I laugh: they're exactly what I would have used! Now, in the case of an image gallery, I'd like to add this cat node to "My Albums" (or whatever - work with me here). I click "Add To Album", and I'm now working with My Albums, My Pictures, My Tags - not Killes' Tags, Killes' Albums or Killes' Pictures. I feel that you forgot "lick" for a tag. How dare you forget that "tuna fish" and "lick" go together! If I'm/me/Morbus is going to remember or tag this node, it absolutely must have "lick"! So, on this "Add To Album" screen, I'm now editing "My Tags" for the node. I type in "tuna fish" (because this is "My Tags" not "Killes' Tags") and I type in "lick". I click "Save". Great! Following along with your desires, we now have: nid about phones | tid for abomination | uid for killes nid about cats | tid for tuna fish | uid for killes nid about cats | tid for lick | uid for morbus What happens when someone clicks on "Morbus' Tags"? With the above layout, they're ONLY going to see "lick". But, but, that's not right! I "assigned" this node "tuna fish" and "lick"! What happened to "my" tag "tuna fish"? In essence, "My Tags" becomes "Unique Tags I've Assigned To A Node". That's not how a folksonomy works (remember, "folks" == "users" == "user-centric") (and yeah, I realize that you know nothing about delicious, so no worries). Here's a visual sample at delicious: # all the URLs that user Qbic has assigned to design. http://del.icio.us/Qbic/design # all the users & tags that have annotated a particular URL. http://del.icio.us/url/e7f5da77d30e4fe7ae5bc895b393e724 See all repeated 'design' tags here? A user-centric folksonomy (where the "user" is the "folk[s]" in "folksonomy") revolves around /the user and THEIR choice of tags for a node/, not /the uniqueness of tags per a node/. It doesn't matter that you have already assigned "tuna fish". It matters that you AND I have, however. The more people who assign "tuna fish" to a node about cats, the stronger the association. An assertion can be made: "43 people think this node can be represented with the tag 'tuna fish'". Your approach doesn't allow this. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
participants (2)
-
Gerhard Killesreiter -
Morbus Iff