I found an interesting post on the Drupal support list about finding the right method for using taxonomy in Drupal.
I am using the taxonomy module and have several vocabularies added , several look like this: 'Politics' which has Single Hierarchy and Multiple select, and has several Terms such as 'Countries', 'Groups', 'Ideas', and Item such as countries has 'sub' Items such as 'USA', 'England', 'Germany' etc. Now.. whenever I post a new article or blog entry and tag it, say.. USA, I still need to tag Countries and Politics as well or otherwise when clicking Countries it will show an empty list. Is this the right practice?
I think this is probably the biggest issue when approaching description problems with a content management system. In large enterprise CMS, the problem might require maintaining taxonomies using the sophisticated tools for finding and grouping content based on rules created by the taxonomy tools included with or added to the CMS. But people dealing with Open Source CMS have been left to the task of figuring out how to deal with these same problems with a less sophisticated set of tools tools and plugins.
Fortunately, Drupal has recently added the Views module to at least help admins deal with display issues more easily. Taxonomy management is an area that still needs more attention. But for most people, the basic question about what practices are best suited to taxonomy use in the more full-featured systems like Drupal persist. Do you use hierarchy in taxonomies? Do you just free tag everything? How do you set up taxonomies for the outcome you expect or desire?
Of course it depends on the type of description/categorization you intend to do. To pick the right method for creating taxonomies you need to focus on how you want to extract or display that information and on how much effort you want to expend on maintaining it. The Views module seems like it will give you the flexibility you need in most cases for creating display rules. But what you want to consider is whether or not the structure you are creating will require you to spend time maintaining the views over time. For instance, given the Drupal Support example above, say the admin starts with the following structure in his Politics taxonomy:
- Countries
- Afghanistan
- Algeria
- Andorra
- Groups
- Al-Qaeda
- Amnesty International
Now, say that he wants to display all of the content that comes in under the Groups category, including all of its subcategories. He can create a Groups View and select each descendent term in the taxonomy filter. But I don't believe there is a way to simply say "give me every descendent of the Groups term and show that in my view". If there is a way to do that with Views, I'd love to see it. So instead, he has to select the terms in the filter's select field.
But, say he adds "Animal Rights Advocates" under Groups. Now he wants to update his View. What I think he would need to do to update the view is go back to the Views filter and now select "Animal Rights Advocates" as well. He would need to do that for every term added to Groups.
In the example above, Countries and Groups are facets of description. And while he can choose to create a taxonomy for each facet, he's chosen to create a single taxonomy for the Politics domain and insert facets under each one.
In the past -- prior to the release of the View module -- I've worked around the display maintainenance issues by creating separate taxonomies for each facet. See the taxonomies in use on my blog for instance. Yikes, right? I've used that separation to break up the display of my metadata below each entry so I can show terms broken up by taxonomy, e.g. Subjects, People, File formats. The output looks like this:
Works for that display need under each blog entry. But you'll notice when you look at the taxonomies for each facet that I also added some complexity by using hierarchy within some of the taxonomies, e.g. Subjects and People. Taking the People example, if I wanted a view that only showed Groups of people rather than individuals, I'd run into the same maintenance problem you see in the Politics taxonomy of having to manually update the Views filter again.
To make matters more complex, I am starting to use and love the new free tagging capabilities of Taxonomy for selecting my terms. I started to do this because my Subjects taxonomy is rather large and choosing multiple options in a form Select can be problematic. The free tagging options allow me to select terms much more quickly. The problem is that I've also become accustomed to adding terms using this tool. This change in behavior of "tagging as you go" conflicts with my previous behavior of first adding terms to the hierarchical taxonomies before I blog because as I now add free tags, they end up in the root of the Subject Taxonomy, requiring me to still go back and file each term I add under a parent for the hierarchy to continue to make sense. And because the Taxonomy module doesn't presently provide a way to filter terms in the admin view, e.g. to find the term I just added without paging through the list, this task has become cumbersome as an after-the-fact activity.
Here's what I see in the Categories section when I create entries in Drupal:
This is a tricky issue, because I'm at a point where I could decide to go two different ways: to dump the hierarchy within taxonomies because of the level of effort it requires to maintain; or to continue to maintenan the hierarchy within taxonomies because it provides some value in terms of browsing. I'm sure the browsing of hierarchies is only valuable to me, but when I think about the amount of energy expended compared with value, my gut tells me that it's not worth the effort to maintain.
Doing this kind of hierarchical taxonomy management on a blog is probably unheard of, but in certain applications, e.g. enterprise content management it can be absolutely warranted and/or required. As an information worker I tend to try out different methods for describing and organizing information to help me understand which practices work in different contexts. The last several years of using taxonomies on this blog and now introducing free tagging have helped me see that each method holds utility in different circumstances, but getting both to work together nicely is a bit tricky.
So, this may not be a very clear answer to the question about best practices for taxonomy. It does serve as a cautionary tale about how being very descriptive and maintaining relationships within one hierarchy can leave you with maintenance concerns as you scale up. In terms of ease of entry using Drupal, creating facets within one taxonomy might make it easier to select terms when you are creating new content and doing free tagging using one field in Drupal. But organizationally speaking, that approach seems to presents you with some challenging display and maintenance issues, for now at least.
Comments
09/26/06 @ 16:58
Michael, this post is somewhat timely in that only last night, after serious, serious amounts of time spent searching, reading, installing modules, hacking (largely in-vain) and testing, did I finally concede that the only native way I could find to get Drupal to auto-add menu items that reflected a hierarchical term structure, was by resorting to using Books (Which is only an ideal solution for a narrow range of scenarios to my understanding).
There may still be corners left unexplored but quite frankly, I'm getting sick and tired of conducting all the above research - I just want to get the site live so I can get going. I'm left feeling disppointed in Drupal, but still somehow, remaining a believer (I'm clearly a masochist!).
I'm not sure if Drupal can legitimately label itself a Content Management System (just yet) - Either that, or my definition of CMS is at-odds to Drupal's.
(And I would hold that the definition (in part at least) of CMS intrinsically means automation of taxonomical structure and menu-building to reflect that stucture.)
I think it's close - by that I mean, the infrastructure has the right building blocks and is certainly working towards (at least) that goal of CMS - but there always seems to be one obstacle to realising what one is trying to accomplish... and that obstacle seemingly always smacks one just before the celebration of completion.
If I could sum-up the problems of Drupal in one word (besides documentation), I'd say it is Paths...
... It seems Drupal is great if you want a flat/wide site structure, but try and build hierarchy, and you come up against the path problem. I've tried so many modules that promised to achieve a goal - if they fall down, it seems they fall down because of a problem related to the way Drupal handles (or constructs) paths... and from that flows the problems of menu-creation IMO.
It is soo frustrating.
If you have a small site that you intend to drip-build over time, great. If you have an existing site with lots of content that you're wishing to carry-over, or one that will receive lots of content fairly quickly, and you want hierarchy too, you will have to manually create your menu structure at each iteration... which is either a pain you endure in order to enjoy the undeniable benefits once done, or is the deal-breaker.
Of course, people will say that maybe my requirements are unique, that I should "scratch my own itch", sponsor someone to solve my problem, blah blah... I have to reply: Look, this is one of menu-creation (and paths), pure and simple. The rest I can deal with. One only has to look at the forums to see that this is far from an unique problem.
Of course, that is merely my take on matters, born from my experiences of trying to achieve my goals. I've got 2 remaining avenues to explore and if they fail (and my PC hasn't been smashed against the wall), then I'll probably have to sadly wave goodbye both to Drupal, and the wasted hours and what will end up to be, pointless work to date.
I'll end by just saying that I came to Drupal because I subscribed to the taxonomy-approach and philosophy... I bought-into-it. We're coming upto version 5 and yet it seems some historical problems persist in this area. Talk is more and more to do with adding bells and whistles - I'm wondering if the eye has been taken off the ball... surely by version 5, the fundamentals should be established?
Great post Michael, apologies if my reply is overly downbeat but you've touched a particularly raw nerve for me ATM, so thanks for allowing me to vent-off :¬D
09/26/06 @ 18:03
I am intersted in how you have managed to get the different taxonomies to display at the bottom of your posts. Is the theme code public?
09/26/06 @ 19:17
If I understand correctly, you want a view that shows all nodes tagged with a certain taxonomy term or one of its descendants.
This can be accomplished by specifying a numeric "depth" value in the option field for the "taxonomy terms" filter. If the depth is positive, the view will display nodes in terms n levels below the current term. A negative value denotes infinite depth, causing the view to show all nodes tagged below the term.
-- eric
09/26/06 @ 20:35
1) Anonymous commenter #1, I hear your frustration, but I have to agree that if you want some level of sophistication in the module, you have to get someone to build it. I think Drupal handles the assignation of hierarchically organized terms very well. The display is what is lacking in sophistication. As I point out below, there are problems in execution when you have anything but simple entry description, e.g. assign sibling terms and you get multiple entries listed in a view using the depth option.
2) Anonymous commenter #2 (why are you afraid to at least leave your name?): I updated the blog entry with a link to Drupal Tip #5, showing how to do the terms by taxonomy.
3) Eric: Thanks for the explanation. That Options box is really a mystery. Perhaps the label for that field should be depth or depth options.
I still don't quite get how negative values work. Do you put in something like "-1" ? Does doing that include the term specified as well as its descendents?
4) I tried a view of one of my terms, "Art and Design". Putting 10 in the options field shows descendents, but the Views module doesn't dedupe when you have entries with multiple terms assigned within that Art and Design branch. Take a look at the view here. Not quite what I wanted, but now that I think of it, it's probably what is expected of the module. Another level of sophistication would need to be added to dedupe on the node.nid field probably.
See response #5 below by Ramdak about using the "Node: Distinct" to remove duplicates.
09/27/06 @ 00:51
If your main concern is auto generated menu items that reflect a hierarchy, the category module does this brilliantly. Be aware, though, that it is a work in progress.
There is a 'distinct' option while creating a view based on taxonomy terms that is believed to take care of the dupes issue when a node is tagged with multiple categories.
09/27/06 @ 01:46
Excellent, Ramdak. I didn't see that "Node: Distinct" filter. Adding that does remove duplicates nicely. Sweet.
09/27/06 @ 11:04
(I am anon #2)
Thanks! I have been wanting to do that for a long time!
09/28/06 @ 21:08
(I'm Anon #1)
RAMDAK: The Category module was one of the options left to try as it happens.
And I began shortly after posting my 1st reply above and whilst it is without doubt, an awesome project (with a good offering of documentation too!), it's not straightforward and looking at the issue queue, far from a finished article either.
I've not given up on it yet - I want to make sure I'm working it correctly first - but I'm not going to be devoting weeks trying to "shape" it to work either (I've "wasted" enough of them already).
Whilst I know you meant well, (I had already decided to give it a go anyway remember, so this is a mute point in my case), I don't think the Category module should be recommended to anyone just yet - not without warning anyway. There's just too many outstanding issues. Couple that with the fact that it seriously alters the internal workings of Drupal, and that the module author spends little time on it, and will be totally unavailable next year, it seems set to never reach the potential it deserves, IMO.
10/10/06 @ 12:25
for auto generating menus from taxonomies try taxonomy_menu, by default it shows nodes from child terms too (infinite depth I think).
something like taxonomy_menu should go in core, my only beef with it is that it uses it's own paths instead of the taxonomy/term/tid paths.
as for path yes I'd love to have the option of paths that reflect site structure based on taxonomy or node type and not do it through url_aliases table.
02/06/08 @ 15:59
I'm new to Drupal. I've been using wordpress. What's the difference between Drupal and Joomla?
02/21/08 @ 15:41
Darrin "Foot Detox" Reservitz:
hope this might help you
Mambo(Joomla):
The user and administrative interface for Mambo(Joomla) was one of the best-designed options on our shortlist. We were also interested to note the emergence of Soapbox, a Mambo(Joomla) toolset geared towards the nonprofit community. The Soapbox toolset is however limited (at this point) to integration with the Democracy in Action CRM, and to single sign-on among sites. The information architecture of Mambo(Joomla) itself proved incompatible with the telecentre.org project, since it is structured around categorization (rather than tagging), which in practice imposes such limitations as precluding multiple categorization of inbound RSS feeds. Since much of the telecentre.org network’s content will need to be distributed to multiple categories (e.g. a story on a Bolivian wifi project needs to be tagged “wifi” and “Latin America”), the categorization structure was a deal-breaker.
Drupal:
With a fast-growing user base in the non-profit sector, Drupal’s strong online community focus made it an appealing prospect. Most importantly, Drupal was alone among all CMS options in its compatibility with a distributed network approach. The platform is essentially built for exactly this kind of approach: it supports ubiquitous outbound RSS feeds, complex aggregation of inbound feeds, per-feed or per-item non-exclusive tagging, and native support for blogging. Compared to the other options, which are virtually all CMS platforms that have developed distributed community features, Drupal is innately oriented towards community networking and distributed content creation. The following outlines how we anticipate using particular features of the Drupal platform to support core elements of the telecentre.org web strategy.
A great place to start is OpenSourceCMS, a site with user reviews of pretty much all the major players in the CMS space. What sets them apart is that they also provide live demos of each CMS they cover. You can actually log in to the front end or the back end of each one, reconfigure it, and make changes to your heart’s content. Every two hours they “reboot” and put everything back to a fresh install. It’s a great way to experiment without having to go through all the time and hassle of installing each system yourself.
Installing Drupal and Joomla on my host
In addition to testing each platform on OpenSourceCMS, I also wanted to install them myself to gauge how easy they would be to work with. Fortunately my hosting provider, Host Gator, uses a product called Fantastico which makes installing Drupal and Joomla as simple as a few mouse clicks. Both installed successfully with minimal effort. Purists abhor Fantastico, but for my purposes, it was a quick and easy way to get up and running quickly to be able to start kicking the tires of each product.
Installing Drupal and Joomla locally
As I’ll need a test environment before long, installing both products on my local machine is a good idea as well. Before I can do so, though, I need to install the LAMP (or WAMP) stack commonly used by Open Source software. LAMP enables my desktop to act like a web server, so that I can run everything from my local machine just as if it were running on my host.
For the curious, LAMP stands for Linux Apache MySQL PHP, and they are the four products that make up the foundation that Drupal, Joomla, and countless other products use. WAMP is essentially the same thing, but uses Windows as the operating system. Each product offers its own installer, and I got WAMP working on my local machine in no time.
The local installations of Drupal and Joomla were a bit more involved. I had to understand how to setup MySQL databases, and know the right answers to a number of questions, although the wizards that each product offered were pretty good. A complete novice would probably be overwhelmed, but I found it pretty much a snap to get both going quickly.
Use Mambo(Joomla) when:
* you don't know about the tech stuff at all
* you want easy install & setup with your mouse
* you don't want to learn the tool you're using
* you don't need to integrate other scripts etc. to your site
* you want a candy site and don't mind several other sites using the same template(s)
* you don't need SEO out of the box
* you don't care about server resources
* you're running (or planning to to run) only one or max a couple of sites
* you don't need one log-in to several sites
* you don't need user groups & permissions
* you don't run membership site(s)
Use Drupal when:
* you want a rock solid & high quality platform for your sites
* you want or need a real multi-site-feature (only one installation for several sites)
* you need any kind of user groups & user permissions
* you need to run also membership- and community sites, not only CMS etc
* you want a Powerful templating system
* you're ready to invest a bit of your time in order to realize all the huge possibilities of Drupal
* you understand the meaning of clear, high quality code and API (easy to integrate with other solutions etc)
* you want flexibility and don't like limitations
A number of Major Advantages of Drupal over Mambo(Joomla)
With Drupal, you can set up several sites with only one installation ...think about that, when you have tens of sites and security holes are found almost daily! ...what about then, when you quickly need to uppdate some additional components / modules / themes... you actually face a lot of work in Mambo(Joomla) - in Drupal you do it only once.
With Drupal, you can (if you want to) use the same log-in-details for different sites... in some cases it opens quite interesting possibilities.
Drupal has also SEO-friendly URL's out of the box... for Mambo(Joomla), you need to buy a commercial component from a core developer or use labor-intensive free ones.
Someone mentioned, that Drupal is focused on communities... you're right... however, it does not mean, you can't use Drupal for content sites. Actually, Drupal is a great choise also for content sites. I can't imagine Mambo(Joomla) as a natural community building system, though.
When talking about user profiles and permissions to different parts of the site, Mambo(Joomla) is actually a joke... on the other hand, Drupal is the opposite... it's so easy to set up and fine tune different user-roles and give them some permisssions etc
Post new comment