Taxonomy's unused tables: related terms and synonyms

fago__: drupal doesn't use them for anything, afaik
fago__: so it's up to contribs to add value to them
agaric: http://drupal.org/node/148080
bot_module: http://drupal.org/node/148080 => Add related terms & synonym editing => Node Auto Term [NAT], Code, normal, patch (code needs review), 1 IRC mention
agaric: And contribs are just starting to do so. But one would think that somewhere taxonomy would have a written rationale for having them in the first place?
fago__: I'm not aware of any.. but yeah, for what synonyms are thought is quite obvious
fago__: however, it's sad that drupal doesn't respect them for autocompletes afaik
fago__: perhaps this would be an idea to improve it..

agaric: Yeah, that would be awesome. It's related terms that's got me confused when I look at a database table getting created for each term. Anyway I was thinking that terms would start out as related, and if considered truly the same, would turn into synonyms.

agaric: I'll try to do the autocomplete on synonyms as I get into that area

fago__: no, related terms and synonyms are different things. however, what related means, is completely open..

agaric: I know related terms and synonyms are different (well, now I do)... but for democratically handling terms, I was thinking that with a few votes terms would be related, but at some threshold of community opinion subordinated related terms could become synonyms

fago: anyway, back to the synonyms :) So the users would vote that the two terms are synonym?
agaric: yep... with some way to register which one they think should be the name of the term

fago: and for what would you use the "relation" then?
agaric: Well two terms wouldn't be synonyms as far as Drupal is concerned-- synonyms don't get a term ID.
agaric: so the folding terms into synonyms shouldn't be done until a real consensus emerges
fago: agaric: yes, but you would need some kind of weighed relations anyway.
fago: agaric: perhaps it's better to just create your own table, for storing votes
agaric: yup... that's why I'd asked that question about adding columns to core tables, and if that's not a good idea, it looks like I should probably leave related terms alone for now
fago: agaric: using related terms for that, buys you nothing..
fago: agaric: yeah. there was interesting discussion about this on the devel list during the last days.
agaric: I actually should do more mucking around before discussing at this level of detail... haven't had a chance, unfortunately. What should we get clear on the more abstract project management side of things?

flk: you could extend the terms_synonym tablewith a table that holds the votes/weights
fago: flk: But then, the terms would be already synonyms
fago: flk: furthermore, adding columns to core tables might create troubles with upgrades later..

agaric: terms have to be in use as separate identities for community-managed taxonomy to be really useful.
agaric: And synonyms share one term ID

agaric: so I need to track term relations, with the possibility of later formally merging terms and creating synonyms
flk: tsid
fago: agaric: yeah, that fits. What are your plans about the votes? Can users give their votes weights?
fago: And have you also thought about other votes, like a vote to place the term under a different parent, or in mutliparent hierarchies to add another parent?
agaric: I wasn't thinking weights... hmm... more harass a friend into voting your way if you need to outweigh someone ;-)
fago: yes, I think it suits without weightening
agaric: That's most of it really. OK, so freed from the idea of using the vestigal related terms, I'll kick this off with a table schema

flk: agaric: there is a synonym table
agaric: yes
agaric: but in 4.7 I see a tid and a name
flk: that uses tsid as the primary key
agaric: so it's just a way for one term to have multiple names
agaric: not a way to relate two or more terms, right?
fago: yes
flk: yes

fago: have you a list, for what do you plan to let people what? (parent change, multiparent, synonm, .. ?)
fago: grml, -what, +vote

agaric: merging as synonym would be a side effect I thought-- and maybe I could make use of related terms the same way -- to make the messy democracy accessible to other modules in a Drupal-standard way
agaric: fago, I think I get what grml stands for (which operation) but could you spell out what the letters literally stand for?
fago: agaric: but what would it mean if two terms are related?
agaric: that some people think they should be synonyms
agaric: ahh, but then I'd be screwing with the way other modules might be using related terms
fago: agaric: :D, it's aimed to reproduce a voice.. so the letters have no special meaning.. nevermind
agaric: :-)

fago: agaric: yes, and the other modules wouldn't know if just one person or ten think it should so
fago: agaric: and then you have this all for synonoms, parents, .. and modules won't be able to tell the difference?
agaric: eh, it could be an option... but anyway it would be an afterthought to the way the module works
fago: so, just make your own table and write some clean API functions, if you want that other modules can participate

agaric: You'd have to know you're making a taxonomy community-managed. So other modules that use that taxonomy should be happy with the resulting hierarchy structure
fago: yeah :)

fago: another thing, what have you planned for the thesholds? when does your module apply the votes?
agaric: Thresholds I sort of thought would be first-come, first-served.
agaric: I'll start without a threshold at first, if it leads to unsettlingly frequent re-organizations, we'll rethink
fago: agaric: so with no treshold, you mean, I vote for the term be a synonym, and it is?
agaric: to the world, yes. But we secretly keep track of which nodes are tagged with the synonym