More about Taxonomy
Taxonomy is more than just a module in Drupal. It is also the study of classification and a research area of information science in the digital age. Drupal admnistrators who want to push the limits of the Drupal taxonomy system might want to read how it applies to Drupal taxonomy module development.
The taxonomy module is one of Drupal's strongest and most popular features because it makes our lives easier and brings goodwill to all. This is because the taxonomy module allows authorized users to (1) tag content using custom labels (aka terms), and (2) automatically classify new content based on this taxonomy. This makes for truly flexible information classification and retrieval.
How is it done? There's a technical and a storytelling explanation. Let's begin with the technical explanation:
The taxonomy module allows you to define vocabularies which are simply a collection of terms (similar to Gmail "labels" or Flickr "tags"). You can define 2 kinds of relationships between terms:
* Hierarchical: indicates a parent-child (vertical) relationship like cat and dog are children of mammals)
*Assocation: indicates a "similar to" (horizontal) relationship like mammals is similar to animals.
Using these relationships, the taxonomy module allows multiple lists of categories for classification (or controlled vocabularies) and offers the possibility of creating thesauri (terms with horizontal relationships) and taxonomies (terms with hierarchical relationships). To delete a term choose edit term. To delete a vocabulary, and all its terms, choose edit vocabulary. {comment: The emphasized sentence actually sounds out of place here. Please suggest how it can be reorganized.}
{factor next para into the main text}A controlled vocabulary is a set of terms to use for describing content (known as descriptors in indexing lingo). Drupal allows you to describe each piece of content (blog, story, etc.) using one or many of these terms. For simple implementations, you might create a set of categories without subcategories, similar to Slashdot's sections. For more complex implementations, you might create a hierarchical list of categories. {/factor}
Still confused? The story below will show some examples of what the taxonomy module can help you do:
Case 1 (simple example). Abel sets up a website that contains his music reviews (posted as stories). Abel uses the taxonomy module to create two terms called Reviews and New Releases. Under Reviews, he creates the following child terms: Jazz, Folk, Classical. He then binds these terms to the story node. Now, when Abel posts each of his reviews, he gets a taxonomy dropdown box that prompts him to classify his review. If Abel classifies a review as Jazz, the story automatically gets displayed in the website's "Jazz" category.
Case 2 (intermediate example): Yoyo Ma, a classical cellist, releases an album where he combines Jazz with Classical styles. Abel now cannot decide whether to classify his album review as Jazz or Classical. Abel fires up the taxonomy module and modifies the taxonomy -- now, instead of allowing only one-to-one tagging, he allows multi-tagging. Abel now tags his review as both Jazz and Classical and everyone, including Yoyo Ma, is happy.
Case 3 (complex): Abel's music website grows and it now contains stories, blogs and forum discussions. Beth and Ching are both contributors to Abel's site. As they post content, they are also asked to tag their contributions. {to be continued}
It's Case 3 that I am most interested in.
I'm developing a site using Drupal which will rely heavily on stories, essays, and articles submitted by a number of different users. These folks will want to just write their stuff and post it. They can use the menu navigation feature of the submission/posting process to determine to which menu (custom ones previously created by me and/or authorized moderators) the piece should be associated. [The default behavior is to list unsorted menu items in alpha order, a perfectly acceptable practice. Myself and moderators can further modify the order of menu items by assigning them weights.]
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?
So far all I have read are excuses like "well, you can and it's cool", "it will help people search for things later" (assumes an otherwise poor search facility is all that is available ), or "you either get it or you don't". This last one being the worst response. A typical refuge of communication-impaired people who like to think themselves more powerful and wise through possession of secret knowledge. Are we expected to embrace a system simply because a system can be constructed?
I picked Drupal after trying other CMS approaches because it puts forward clean, nice-looking pages fairly easily and contains a nice set of optional features (unlike Mambo and Nuke systems which seem to assume everybody screamingly wants to know what's hot, what's not, who's popular, and the latest gossip). But I am not convinced Drupal developers must also buy into the theology or dialectic of the supremacy of taxonomies. Could it be something as simple as because a Drupal-type CMS is based on a database application (like MySQL), a taxonomy-based approach is the easiest way of making the system rational and more humanly understandable?
Cheerily Yours,
Tim O'Laguna
value of taxonomies
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.
"Association" type relationship
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."
Mammals is a subset of animals
I think you are missing the forest for the trees --> ignoring the bad example, he was trying to illustrate an equal level. Perhaps you can think of it as mammals and reptiles.
Taxonomy tax-onna-you
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
Automatic tagging
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.