Hello there,
I´m working with Drupal some years now, and everytime I need to set some sort of classification, I think always in taxonomy. So I create some taxo vocabs and terms and everything goes smooth.
But recently I started to rethink my way of doing it, and started to play with CCK list fields.
You can work with them in a flexible manner, and it does have excellent Views support. You can show them in views and use them as filters, exposed or not.
So, overall, replacing Taxonomy terms for CCK text list fields are OK in my book.
But as I´m feeling fine with this recent discovery, I have this bad extra feeling that tells me that I´m forgetting something big here.
Taxonomy is different of all lists created by CCK because... I just don´t know.
I would like an insight about this, get to talk about it. Am I wrong? Is there something that I can do with taxonomy, that cannot be done in any other way? Maybe some ver important contrib module works only with taxonomies?
Is taxonomy going to slowly dissappear as a module?
I would like to hear your opinion on this.
Thanks!
Rosamunda
Comments
A list of tags can be
A list of tags can be implemented as cck fields.
But either one have to improve views or write a separate module to maintain the relationships between terms.
Clearly, if all you want is to have a list of tag without a need of relations, CCK + View is enough. But I will call it a tag system instead of a taxonomy...
When to use taxonomy
I think that there are a number of cases where taxonomy is preferable to cck.
1) When you have a lot of terms. Because taxonomy stores values with an id and not as plain text, taxonomy can scale between than a cck field.
2) When you are representing hierarchical relationships.
3) When you are going to re-use the classification in multiple places on your site and expect to edit it regularly. I find that it's easier to make changes to taxonomy than to a cck field. I also don't like letting more than a few people administer my content types.
I tend to only use cck fields when I am listing attributes such as the color options for a sweater on a sweater node.
There's also an intermediate option which is to create vocabularies and then reference them with a CCK field, content taxonomy.
I agree with you, I'm using
I agree with you, I'm using taxonomy less and less and using CCK for categorization instead. However in some specific cases there is no replacement for taxonomy.
I think that CCK it's more useful when you have a small set of categories or you need to have a category page with some extra info, for example book publishers.
In the other hand, taxonomy is very handful if you need to have a "free tagging" categorization system like stackoverflow.com or you have a large set of categories with hierarchy that you will like to browse, for example a country-state-city list (however, for this last example it's better to use the location module)
So there are situations in which taxonomy is indispensable, but I think that in general when you spent some time with Drupal you realize that it's not the answer for everything and that CCK is a good alternative in most cases.
In small cases, they are
In small cases, they are interchangable.
But lots of what I've been doing treats taxonomy terms as important elements of information in their own right. Heirarchy, re-use, free-tagging is mentioned above.
I use the description field a lot, and we are extending it with lots more. (see taxonomy extension modules like taxonomy image, taxonomy_enhancer). Synonyms etc. Unique Identifiers, meta-information about the terms themselves.
Not always, but often enough for me to just not use the CCK approach unless I'm tagging/classifying known, small, immutable lists.
usage of taxonomy
For our presentation at DrupalCon DC, we came up with this way of describing taxonomy.module, its relevance and utility. Think of taxonomy.module (and all Drupal modules) as a prescription drug from a doctor. In American English (does this metaphor work for other people?), drugs have on-label use and off-label use. A drug or treatment is developed for very specific medical objectives (the on-label use), but many drugs are useful in other circumstances or may have other properties especially when combined with other drugs (the off-label use). A smart doctor will know when to prescribe a drug for off-label use.
Taxonomy.module's on-label use is to create and maintain controlled and tagging vocabularies. You use these vocabularies to classify the content on your site. There are really really huge vocabularies in the world, and while Drupal core does not include a straightforward way to use these vocabularies yet (though Dman has a way!), it would be difficult (for me at least!) to bring these vocabularies into a CCK field's list of options. And JuliaKM is right to mention hierarchy. If I want a vocabulary of place names, CCK is not set up for understanding the kinds of relationships we'd need: El Paso is in Texas is in the U.S. is in North America, but also El Paso is near Juarez in Mexico, and Texas is related to Mexico, colonial Mexico, etc.
However, Drupal is flexible and new modules affect the utility of Drupal's core feature set. An off-label use of Taxonomy is to add more details to your content: the name of a client on a web developer's portfolio web site or the formats of video tapes a camera store might sell. What makes taxonomy compelling for many users is the easy linking between the node and the taxonomy/term/% page, because CCK + Views don't do this automatically. (However, I am going to follow this up with a post to the group that documents a method for making CCK fields do some of the things taxonomy terms do.)
Taxonomy.module's future depends on improving its ability to support vocabularies. I only see Taxonomy.module disappearing if this use case becomes marginal or if Taxonomy.module can't support vocabularies very well.
Thank you for your insight!
I think I have a more accurate idea of why taxonomy won´t be deprecated after all.
And I think it will improve on D7, because it´s very powerful after all.
Thanks!
Rosamunda
Taxonomy Views
Thought provoking discussion. It seems the major reason to use CCK in place of Taxonomy is to better expose the terms to Views. So maybe this discussion now asks the question, how can Taxonomy improve its flexibility and exposure to Views?
Same view
@sstedman,
Exactly what I feel too. At times it becomes a bit easier to use CCK fields and Views.
I guess the Content Taxonomy bridges this gap to a certain extent and I plan to keep using it until I understand the Drupal internals better.
Also one other thought that comes to mind is that, of the 2 options (CCK fields and Taxonomy) is any one of the two, a more efficient option in terms of performance, at least for smaller uses which don't require hierarchies, say for a Movie's genre?
tagadelic+views
For taxonomy browsing and views support I am using tagadelic + tagadelic views!
Stable?
I just read the issue queue for tagadelic views, and wonder if you've found it to be stable?
convert nodes into a taxonomy?
I find this discussion of interest.
In my site at www.dance-ottawa.com, it is currently setup to use CCK node references to a content type called 'dance styles'. Several of my content types including dance-school, nightclub, and dance-event allow 'dance-styles' references to be specified when they are created. This works, somewhat.
I originally decided to use a content type for dance-styles so that I could add text descriptions, videos, and various views to each dance style page.
But as the site gets more and more use, Im regularly asked to add new dance styles, or new parent-child relationships between various dance-styles.
I'm starting to think it might be better to get some of the features of taxonomy, such as free tagging, ang tag cloud displays.
But this discussion has me somewhat concerned, what advice would people have someone changing a content type into a heirarchy.
if heirarchies are being used less and less, should I even consider it?
if cck is moving to core, should I wait till drupal 7?
and just in general, with about 1000 nodes on my site that currently refer to the dance-sytle type using CCK, does this seem like a horrendous task, and should i should be considering at all?
what advantages could I gain if I switch a dance-styles content type into to a dance-style heirarchy, and should i consider using content-taxonomy to save myself some work in the migration?
Thanks!
Another option
You might want to consider adding a node reference field called parent to the dance styles themselves. Then you can maintain your existing setup, and manage hierarchies of any depth level.
You might have to make some tricky views to actually show your categories in a hierarchical fashion, but making views that link to a dance styles parents or to its children wouldn't be too bad!
Hope this helps,
-Karl
edit: or you could do it the other way around and specify links using a "children" node ref field.