Tag hierarchy absence - design reasons? [duplicate]

Question

Possible Duplicate:
Implicit tagging hierarchy

I've seen some references on MSO to the fact that Jeff rejected (supposedly repeatedly) the idea of a tag hierarchy. However, my searching failed to uncover any source material (e.g. actual wording by Jeff/Joel) on the topic.

As a developer, I can see a couple of obvious downsides to having tag hierarchy from the technical standpoint - but as a good developer, I can also see solutions to ameliorate those downsides.

Which leads me to believe that there must have been non-technical (e.g. design, usability, or philosophical) reasons as well. I was wondering if there is any such detail available, or if not, if Jeff or someone else on SO team could be so kind to comment on it?

(In case it is not obvious, I think that tag hierarchy would tremendously help the usability of SO - matter of fact it is one of the only two big improvements of the SO/SE I can think of that would make the site design perfect in my eyes as opposed to just great).

UPDATE: Based on the feedback from this question, I have posted a proposal for tag hierarchy on MSO.

Answer 1

The tag information is neither completely flat nor completely hierarchical, and I think this is what's freaking Jeff out.

As mentioned, there are a lot of situations where the context of a tag is ambiguous (meaning a flat system is favourable), but there are also very good candidates for using a hierarchy, where the meaning of the tag is unambiguous. For example, right now we have flat tags of: [visual-studio], [visual-studio-2010] and [visual-studio-2010-express].

I think it was decided that the tags are more flat than hierarchical. There are tradeoffs between both systems. That being said, I don't see why a hierarchical system couldn't be implemented where only unambiguous tags get put into a hierarchy and everything else is left flat. There could be additional authorization rules where you need more rep to create a tag hierarchy than to create a flat tag.

The planned tag synonyms will cut down on a good number of tags, but I think it's still a supplementary measure to the main part of tag organization.

Answer 2

There are enough problems with the spellings of single non-hierarchical tags and creation of singular vs plural tags, and acronyms vs full names, etc. Can you imagine the extra causes of tag-wrestling if you have hierarchies too? Does ".net" start at the top, or does it have to start in the "microsoft" hierarchy? What about if it is the "mono" version?

Another problem - search. I want to look up stuff related to, oh, memory allocation. Is that 'memory-allocation' or ('memory' and 'allocation')? That's the current problem. Now, in a search in hierarchical tags, does specifying 'memory-allocation' find that tag under the 'c' and 'c++' and 'java' and 'c#' (or is that 'microsoft/c#' or 'microsoft/.net/c#') hierarchies?

Etcetera, etcetera.

The flat namespace and limit of 5 are both sensible, simple, pragmatic ways of organizing things.

Answer 3

The more I use the trilogy, the more fond I become of flat name-spaces for classification. It has been my experience that in any sufficiently large community you run into issues of how to create taxonomically satisfying hierarchy that most people will understand.

For example, at work the intranet site for finding classes has had a hierarchical listing of the classes and despite 4 years of hashing back and forth we're still having a bugger of a time listing things in a way that makes sense to the majority of users.

Despite usability test after usability test, in a narrow field, it's just easier to use the SO-style tagging (which I'm working on implementing in the next version of the site).

Am I saying its impossible? No. Please don't hear what I'm not saying. What I am saying is that outside of specific criteria, its not worth the effort.

Answer 4

Tags probably should be mostly flat, and only have relationships where there is a very strong subsumption of one by the other. For example, I'd expect ruby-on-rails3 to be subsumed by ruby-on-rails. Have relationships between tags only be settable by people with very high reputations (e.g., another 10k perk).

As to what to use them for, the obvious things are searching and filtering. If I was to filter out ruby then I wouldn't want to see ruby-on-rails3, yet if I was searching for something about ruby then an answer tagged with ruby-on-rails3 might well be useful. (Yes, we could wish for people to be perfect about tagging, but meanwhile there's a need for something workable now.)

I wouldn't try to encode the relationships in the name. Too many cases where that's not useful (e.g., jdbc would be subsumed by java).

---

[EDIT]: It probably also ought to be more expensive to sponsor tags "higher up" the tree.

Answer 5

Designing abstract hierarchies is an almost impossible thing to get right, which is why so many novice OO programmers go astray when thy try to base their design on such a hierarchy.

Consider for example, the C++ tag should it:

• be rooted under languages
• be rooted under OO languages
• be a root tag itself, with sub tags for OO, Generic and non-OO programming?
• be rooted under Microsoft
• have subtrees GCC, MSVC etc.

and so on and so on. There is of course no correct answer. One constructs such trees depending on the task immediately at hand.

I do think however, that the ability to create tags at all should be restricted to (say) 5K susers.

Answer 6

Tags are created by users. How would users create tags in a hierarchy?

---

I mean, how can a diverse collection of users, from all around the world, be expected to agree on a single hierarchy?