More about Taxonomy

You ask: So why should our contributors be further required to "classify" their material using terms I have created? Why put them through an unnecessary workload hassle?

I think the reason to do this is that if you have n contributors adding m > n content items on a regular basis, keeping all that content organized is daunting to impossible for small support staffs. But if the contributors can describe their content easily (a key question) then the content can become largely self-organizing.

If you have such a simple site that the organization is predictable and monolithic, then there is no additional value to the tags, at least until you change your mind about your site's organization.

So far I haven't seen on the site any discussion of complex sets of taxonomies in Drupal. Pointers welcome.

I don't understand from this why or how you'd use the "association" relationship type.

Mammals and animals strikes me as a bad example because "mammals" is a subset of "animals."

It's a pain to have that extra work, and I think that if you're doing (as in example 1) a fairly small, straightforward site, it doesn't make sense to tax people with the extra burden. However, (as I understand it) the value of this lies in creating a huge site where a fluid info architecture is useful. Let's say, for example, you're creating a site for a shopping mall that will have all the subsites for each store. Let's say that you want to create dual navigation through the scads of information on this site.
Version A is the straightforward nav that breaks things down by store, then by type of item, then item. Easy. Done. The second kind of nav is sitewide, and is a task-oriented navigation, and breaks down as type of item - sub selector - sub-sub selector. So someone looking for shoes could go to the Footlocker site and look at men's shoes, then cross-trainers, then the specific shoe they want. But what if that shoe is in The Athlete's foot and not Footlocker? If someone isn't familiar with the product line of each store, they would have to look for their shoes store by store until they found them. By creating the other task-based nav, they can go to Shoes->Men's Shoes->Cross-trainers, and get listings of all items inside that term, from all the stores. So why not JUST use that nav? Well, what if someone likes shopping at Footlocker because the sales people are helpful, and only wants some sneakers to wear around, but don't know if they want running shoes or cross trainers? The first nav structure would make sense.

I realize that the mall example isn't perfect, but it illustrates the idea, and illustrates why people are excited about it. It creates a fluid navigation that can assign 1 item to multiple homes, and allows you to have audience-focused architecture that doesn't depend on an informed audience to find what they need.

I'm new to the whole taxonomy idea, but just thrown deep into 2 HUGE projects (on the hundreds of thousands of dollars scale) where it's a huge part of what's going on, and one of those is a Drupal project.

-Shazaam42

I can see where Tim is coming from. I'm currently developing my first complex website(a personal project) containing listings, forums, articles, galleries, databases etc. Now lets say you want a retailer to add a listing so it can be found by visitors by Country, then State.

Option 1 - is to setup and use the vocabulary for tagging. The problem with this is the retailers country and state is not available for others to see as information. They see tags(the data part), but to the average Joe, this jumble of words is just that.

Option 2 - we can setup CCK fields in addition to term selection. Now the retailer is really confused; "why do I need to select my location twice?". That's a good question...

Option 3 - use a module such a Content Taxonomy to define taxonomy fields in your content type. Select the option to save the field selection as both a tag and in the CCK table. Now when the retailer submits his location, what's displayed is actual information.

Option 4 - Why store data twice? Lets just move the tags in a place and order on the page so it's interpreted as information. I'm not good at theming. If you know how to order the tags and display a heading above them please tell.

Tim wrote: So why should our contributors be further required to "classify" their material using terms I have created? Why put them (and me, who would have to spend time creating vocabularies and terms) through an unnecessary workload hassle?

I'm just starting to learn Drupal... but it seems to me that if the custom menu items that you created are specific enough relative to the topics of the users' contributions, then I agree. I don't see a reason to make them further classify their material. But if your menu items are very big topics and there's likely to be a great diversity of material going into each topic, then it seems to me that you do them and the people using the site a favor to assist with getting the material further sub-clumped. If you leave that to free tagging, it likely won't quite work. E.g., if your topics are "Food," "Cars," and "Houses," and one person writes about raspberry cheesecake and another person writes about cranberry cheesecake, it's quite possible that one would select "Food, Dairy, Raspberries" and the other would select "Food, Cheese, Cranberries," and the two pieces end up in random parts of the Food section -- whereas if you'd given them vocabularies to choose from they would have come up with "Food, Dairy, Cheesecake, Fruit, Raspberry," and "Food, Dairy, Cheesecake, Fruit, Cranberry" -- and they'd travel together.

Or, if you've had as much hassle as you can handle this week and you'll throw in the towel if you spend one more minute in front of your computer, you let them go ahead and self-tag and figure that at least the web site exists...!

Karin

I see your point, but when you look at it from a user's perspective, you're also probably wrong. Search is not a replacement for a categorization system. Search lets you find specific things, and that's great and awesome and sometimes exactly what I need. But sometimes I don't want that degree of specificity, I just want to browse. And search tends to kind of suck for that. If I just wanted to browse, oh, all the articles specifically about music, I wouldn't use search because that's not really what it's designed for - I'd look at the way the site owner taxonomized it in hopes that they had a music tag.

It might be possible to duplicate that with a good enough search engine, that showed all the articles fully expanded (which is the single biggest weakness of using search as a taxonomy, in my experience), but I don't think I've ever seen that. Non-writing based sites have it a bit easier, in that I am more willing to use search to browse through a shopping site, but it's still not an entirely good proposition for another reason, and that's a bit more complicated.

Basically, the nature of a search when using it to browse isn't to find things exactly - it's to exclude everything else. When browsing through search, you're going to be missing things you might be interested in because you don't somehow magically know all the contents of the website you're searching. If you did, you wouldn't be searching it. So you're going to miss things. The point of a taxonomy in that sense is to give people a way to browse through the parts of the site that they're interested in, while giving them reassurance that they're only missing the stuff that they're genuinely not interested in.

I'm sure there's sites that can get away without extensive taxonomies, but it's never going to be ideal for your users. Sometimes the tradeoff of the extra work to categorize it is not going to be worth it, and that's okay, for much the same reason that I take downright spiteful glee in not bothering to make my CSS work on IE when I'm designing personal sites that I don't have to give a crap about being universally accessible. Sometimes, it's just not absolutely necessary to put in the extra effort, and if you don't enjoy it, then there's no particular reason why you should bother. But if you're designing something to be used, rather than something you're doing half for yourself and for the fun of it, then yeah, taxonomies are useful.