complex hierarchical taxonomies in drupal?

I’ve been struggling with this problem for some time now, and am a bit stumped. Bits of it are trivial to solve, but when I start hooking things up, there’s a pretty big gap and disconnect.

On the surface, it’s a simple problem. I’m using Drupal, and am building a website to store things like profiles for individuals. That’s easy. I need to add lists of the degrees they’ve been awarded. Like this:

D’Arcy Norman

  • Bachelor’s of Science, 1992 (University of Calgary)
  • Bachelor’s of Education, 1994 (University of Calgary)

Sounds easy. Could just be a CCK content type, with a text field that allows multiple values. Enter whatever text you want.

buuuuut…

I also need for the site to be organized such that I can list everyone who’s earned a BSc in Zoology from UCalgary, or everyone that’s earned a Bachelor’s Degree in 1992, or just people who have earned a BEd from UBC in 1998. Or potentially any combination or permutation.

So, simple text fields don’t cut it. They solve the display problem but not the data modeling and querying problems.

Taxonomies seem like the natural way to store the data – I can set up a Taxonomy vocabulary to represent the full hierarchical structure that is needed.

The problem with a hierarchical taxonomy is that I can’t seem to get it to actually display the hierarchy, with the full lineage shown. On the node display page, I get something like this by default:

First, that shows all terms from all vocabularies. In this case, “calgary” and “ucalgary” are from the Tags vocabulary, and “Bachelors” “Education” and “Science” are all from the Degrees vocabulary. Except they’re all munged together. And the hierarchy is completely gone.

With a bit of custom code, I can separate the vocabularies, like this:

Getting closer. But the hierarchy is still gone. I can’t get it to show something like:

Degrees:

  • Bachelors > Science
  • Bachelors > Education

The specifications call for the end result to look similar to this:

And there’s perhaps an even bigger problem – I can’t associate a year or institution with the degree. Under this strategy, there is no easy way to say Bachelors > Science (University of Calgary, 1992) and have the data be stored in such a way as to be properly searchable and meaningful as opposed to be essentially for display purposes only.

The other thing I’m hitting my head against is the need to keep data entry as simple as possible. Some really nicely designed forms have been sketched out with ease of use as the primary concern. But they’re going to be pretty darned difficult to implement in Drupal without writing custom modules. If ease of use wasn’t such a big concern, I could probably just use text fields for display so I could enter whatever text I wanted to represent the degrees, and have a set of Taxonomy vocabularies to be used to represent the data for querying and filtering. But that’s redundant data entry, and would be very confusing to anyone actually entering the data.

One other idea I had was to model institutions and degrees as nodes (using a custom content type) and use the node relation CCK field to tie it together. That could work, and we’ve used that technique on other projects (like the Great Teachers website) but I’m not sure that’s the best angle to take in this case.

Any Drupalistas out there with some ideas on how to properly represent multiple bits of hierarchical data to store and display things like sets of degrees granted in given years by given institutions?

7 thoughts on “complex hierarchical taxonomies in drupal?”

  1. CCK can do this.

    Person –> noderef –> Degree

    Degree:
    * type (taxonomy or CCK text field with autocomplete) — e.g. bachelor
    * year (date field, year only)
    * institution (taxonomy, or noderef to a type Institution, or CCK text field with autocomplete)
    * department (taxonomy or CCK text field with autocomplete) — e.g. Science

    Think about each item you are modeling, and think if it has other information attached to it that would be useful to have as first class objects. E.g. Institution would actually have a location, and then you can start doing mashups of degrees across the country 😛

    As modeled above, the Degrees output for one person then becomes “show me all degrees for this given profile ID / user ID” — the degree contains the rest of the information.

    Views Fast Search will let you model an advanced search form based on the fields.

    Think less of inputs and more about data modelling. Multiple node refs are a good way to prototype this…but bundling this into custom relationships may be the way to go long term.

  2. Thanks, Boris.

    omfg. yeah. node relations are totally the way to go. it hit me on the way home. That Great Teachers site I linked to is essentially doing the same thing, but instead of “degrees” it is using “awards” – but it’s the same thing.

    In that case, it’s modeled like this:

    Person -> awarding -> Award

    By putting the Year into the “awarding” level, the Award (or Degree) remains generic enough to be reusable, otherwise we’d wind up with hundreds or more of various incarnations of the same Degree (but from different institutions in different years).

    I’ll try to hack something together. Think it’s getting closer…

  3. Actually, the messy bit is that you HAVE to have one degree per person – year combo — then it becomes a question of how much stuff you want to relate outside of that. But you will definitely have one row per year/person (the data has to live somewhere, it’s a matter of picking your join, and the year+degree related to person is the unique data).

    Reading that, it sounds more complicated than it is 😛

  4. hrm. yeah. that gets pretty messy.

    if this was in custom-software-land, I’d just make it a many-to-many between a Person and a Degree, and have both Year and Institution be additional attributes of the join. But that’s not something that’s readily representable in Drupal parlance…

  5. If you get this working I would love to know how easy it is to maintain. At work we have a requirement to track safety training for various individuals, expiry, etc. It appears that this would have similar requirements. Currently this is done in a crappy MS Access application and I would love to move it to our CMS. I have searched for various HR dupal modules but could not find anything close.

    We already AD to authenticate and store most of the basic information in AD. All we would have to add is the course and date info.

  6. Boris, I think I may have just thought of a possible solution. I’m wondering if this might be a viable candidate for a CCK custom field module? I could define things like “year” “institution” “program” etc… and provide dropdown selectors…

Comments are closed.