If you’ve worked much at all with the open source Drupal content management system, you may have come across it’s Related Terms functionality. To understand it of course you must first understand Drupal’s Taxonomy. When you learn about Taxonomy you will learn that you can assign a node not only to one category, but multiple categories. So the question was raised in the Drupal community, what’s the difference between Related Terms and the Multiple Selection of Categories in Drupal? One community member gave the most simple and best answer yet.
What is Related Terms in Drupal?
There is no intrinsic relationship between Multiple Select. It’s just saying that one thing can be described in several ways. Big. Red. Dog.
Beef Stroganoff in a menu may be categorized using Multiple Select as being both a Stew and a Beef Dish.
That is, this item can be classified in both of these ‘classes’, independent of each other.
Related Terms defines relationships between terms (as you quoted) irrespective of actual nodes.
Other terms related to Beef Dish may be Lamb Dish, Pork Dish, partially because if your recipe book was divided into a chapter that was titled “Beef Dish”, these are chapters I’d expect to see alongside it. A related term to Stew may be Soup or Curry… for the same reasons. This way you can have a recipe book that is divided into chapters on both axis!
… there may be justification for using a totally separate vocabulary altogether for Ingredients vs Preparation, but that’s probably overkill.
Whether you think antonyms and alternatives are “related” is up to you and what you want to achieve. A user manual certainly needs the documentation for encoding to be related to the documentation for decoding, whereas you won’t get much mileage by declaringr Windows Software as being related to Mac Software
There is also Term Aliasing for terms that really are the same thing.
If you don’t fully see the need for using these terms and using this structure, don’t use it! Just because a Taxonomy can be structured doesn’t mean it always should be, sometimes all you want is a list of keywords.
Another Thought on Related Terms
This has sort of reminded me of a search engine, for example Google. When you do a search on Google for “Beef Stroganoff”, you will get results based directly off of your search. But you are going to get related search results as well. You may get a recipe website. You may get a result from foodnetwork.com for some “how to cook” tutorial videos. In the most complicated way, Google provides us with Related Terms and Results for our search queries. This appears to be a manual way to achieve this using the Drupal content management system. I hope my example helps. If not, the one above is much better!
- Digg this post
- Bookmark this post on del.icio.us
- Stumble this post
- Mention on Facebook
This is probably the best explanation of Drupal’s related terms I’ve found. Thank you
I like Drupals taxonomy, but it is limited without thorough knowledge of drupal and programming.
now the full functionality for taxonomy are spread over in different modules, menus and sections in the admin.
If you choose to build your site structure based on one Vocab with hierarchy, there are cons. But is it good that you can put new pages (nodes) in multiple categories without worrying about duplicate content (assuming you have the required modules).
funny thing is there is no tutorial or info on using VOCABS for site structure on Drupal. to fully use vocabs and terms you will need to learn VIEWS EXTENSIVELY and build out blocks of content – then theme everything. otherwise you are subject to limited benefits and poor presentation of content. btw VIEWS requires programming knowledge, no non-coder knows what “arguments” are.
For a menu the links to subcategories(terms) will show how many pages are in each category like; category 1 (23). All the terms in the vocab result in pages that when applicable show teasers of the pages listed (even pages in sub-categories). you can apply the vocab to different content types so it doesn’t show up on all the pages, but if you use if for a menu, then it will need to be assigned to every page type.
Now comes the problems. How do you (easily) theme the category pages. There are not any way to easily alter the default category pages format. what if you want only terms that have content to show in the menu? you have to manually edit the menu. how do you remove numbering of pages under a term? not from the admin. there is no data anywhere on these issues, so good luck figuring it out.
The problem is there is all this good functionality but it requires major theming, and use of other modules because no theming or layout controls or options exist in the admin area.
another problem if you use vOCAB for your site structure or menu. in the page creation the categories (vocab) is listed in vocabulary section mixed in with your other fields. It is not an easy field for choosing among many terms, and can confuse editors since it’s not under “menu”.
what is really cool with drupal is freetagging. but yet agian if you want to apply this to many topics, it is all grouped together on the page as links. there is no admin management of how / where custom fields appear on the page.
basically there is almost NO admin based content layout and content structure control. you need to use VIEWS to generate or control how content is presented – and PANELS for layout which is not even ready yet for 6.0. by the way there are very little info on using views – a core module that is really required for building a decent website in drupal.
the concept of taxonomy and free tagging is drupals top feature, but formatting these functions and presenting them on the page is non-existent. how would i know if I need views, panels or theming in order to present the info how I want? who knows.
what about sub content? what if you have a Beef Stroganoff page and what sub-content like recipes, brands, etc that only apply to that page? it’s a real bitch to associate these pages and feed the sub content into the parent page. the pages need to be created before you can even apply any type of association with each other. there is no way to create placeholder pages. only book pages provide a parent/child structure. instead of clicking a link like in book pages to create a child, you will need to browse ALL nodes to find that parent, or use freetagging to pull up the parent (node reference), and then there is major room for human error in linking the wrong parent.
this chaos just goes on and on.
so drupal used with the default install and page formatting is impressive. try to build out a site with your own site structure, layout and content presentation, and you will encounter problems. I’m not talking hard core functionality or scripting, just presentation of your information. how it is organized on a page and linked together. drupal forgot to include major front-end controls into their CMS.
even my explanations here on taxonomy sound messed up, would surprise me if any of this is understood unless you have actually tried this in drupal
I think Ethen’s last paragraph says it all. He’s such a novice that he can’t even communicate his complaints.
Drupal has a steep learning curve, no one denies that. You have to build 2 or 3 complete sites and invest several weeks before you really get the hang of it.
But if you stick with it, it totally pays off, especially if you are a programmer who wants to create customizations. Drupal’s architecture is brilliant & beautiful.