On Tue, 8 Mar 2005, Morbus Iff wrote:
The whole point of folksonomy is that users make up their own tags.
Quite so. But, I'm more concerned with duplicate data (a technical implementation) and how it should, or shouldn't, affect "users making up their own tags" (an, arguably, UI implementation). If one user creates "cat" and another user creates "cat", aren't they the same thing? Why should there be two unique tags (and thus tids, RSS feeds, etc.)? Is this going to make equivalency code more difficult? If there are two different vocabs, and one user says that "feline" is a "synonym" of "cat", is that information that we want to throw away for every other user, simply because they didn't care or know to create the same (arguably correct in this innocent example) association? And, if not, why should I need to do a join on the user table?
I think it really depends on the use case what you want. if you have a large anonymous site, users will want their own tags. If you have a community site, users are more likely to want to share their tags.
Does /no one else/ want any sort of "similar keywords" UI, per the UI at http://disobey.com/d/2005/similar_keywords.jpg? If yes, then would similar
I do want it. :)
keywords be across all folksonomy vocabs, or just an individual user? If
I would only use one vocab for all users. But that is for my current use case.
there are 1000 users and each user creates 100 terms in their vocab, with a perfect match of (even) 10%, aren't we wasting a lot of resources storing those duplicates? (Note: I suck at math. I have no clue if that calculation makes some sort of scary figure. But, uh, I meant it to <g>).
Terms don't take much space.
Otherwise, you have one central vocab like today. At first blush, it seems you want taxonomy on the fly where users add terms to the central
Correct, but an additional table (whether it be new or profile.module) would associate uids to tids.
I used to do that for groups.module. ;)
I'm having a tough time comprehending or believing that:
* technorati is creating $copies amount of terms called "funny", as opposed to just storing one instance of it and uid joining.
* that my innocent gamegrene site, with two controlled vocabs, is suddenly going to blossom into 900+ vocabs that I have absolutely no control over, nor can ever delete.
What kind of control would you need or want to have? As long as they are not clogging your /admin/taxo page (which private vocabs do not) I do not see a problem.
* that the NHPR site, with 7000 unique terms, is going to store at least 10 times that many (I'd say there are about 80 users/ reporters/ submitters, all who use about 3-10 tags per entry) in your current proposal/design.
For that type of site sharing terms makes probably more sense. Cheers, Gerhard