So I have the idea of Taxonomies in my head and I start to think I know what they are and how to use them, then I sit down at my keyboard and my head starts hurting. I have a few questions to pose to the Taxonomy Ninjas out there.

Do all sites need a parent vocabulary? Why or why not?
I think I read somewhere that it's best to make a root vocabulary for all your other vocabulary and terms to live under. So which is better?

Root Vocabulary 1 (What should this even be? Home?)
-Vocab 2
--Term 1
--Term 2
-Vocab 3
--Term 1
--Term 2

or just:

-Vocab 1
--Term 1
--Term 2
-Vocab 2
--Term 1
--Term 2

How do the varying structure affect navigation and breadcrumbs?

I guess I am trying to start a best practices discussion more on site architecture than taxonomies in general. What are your thoughts?

Comments

ambrojio’s picture

...but only to a point, IMO. Adding a master "parent" vocabulary adds an unnecessary layer to everything. It's the same rule as grade school outlines for research papers: if you have only one item at a particular level, it probably belongs somewhere else. If you only have one vocab at the top level, you don't need it. I have even done sites WITHOUT a taxonomy, if the content was simple enough. Remember the overarching purpose of establishing a taxonomy: to categorize content into chunks that are easier to navigate for everyone from admins to contributers to visitors. How does a master vocab help the end user? Does doing so help them find what they are looking for? Unless you can muster a really specific reason for it, you don't need it. The site's existence, conceptually, is the parent vocabulary. Users begin their search for a widget at widgets.com, and refine that search via the taxonomy. Taxonomy should serve a purpose, and shouldn't be used just because it's the "proper" thing to do.

This is just my analysis as a data architect, and user experience...guy. There may be technical reasons one might want a master vocab, but I have never encountered a need for it.

zach harkey’s picture

One good technical reason to have a master vocabulary is flexibility. There is currently no way to move a term, or tree of terms, between vocabularies. You have to delete them and start over. Let's face it, no matter how thoroughly you plan your taxonomies, there is no way to anticipate the final position of every term once they're subjected to real life, day-to-day use. Keeping everything within a single vocabulary is one way to avoid getting trapped.

Of course master parents have their own drawbacks too: the default Drupal category select forms become exponentially unusable with each level of hierarchy. Thankfully the new Content Taxonomy module lets you fine tune taxonomy select fields on a per node-type basis. For example, you can crop the options available to a particular branch, and even customize the presentation and field descriptions to aid the user.

-zach
--
harkey design

: z

erikhanson’s picture

Yep, term lock is a bear. But the way I was setting the secondary vocabs under the main parent was locking me down too, at least if I needed to jump parent vocabs. I did some testing after the post on one of my test sites and really didn't notice a difference in the two set-ups except for an extra level that seemed to get in the way when it came to actually looking at the resulting URLS, so I think for now I get rid of my master vocab and use the vocabs where needed. I'll get toying with this idea though.

michelle’s picture

Yeah, that's a neat module... Unfortunately, it has far too many bugs. I found it unusable and had to give up on it. :( Pity because it would have worked quite well for my profile page.

Another option is to use the taxonomy batch operations to pull in a bunch of terms at once. If you keep your terms in a text file, you can put that into a new vocab should that be needed.

Michelle

--------------------------------------
My site: http://shellmultimedia.com

erikhanson’s picture

I agree with you that the sites existence should be the parent category. Too many ways to skin this cat I guess. Thanks for the input.