Posts Tagged ‘tags’

Hierarchical Structures: Do we really need them?

Posted on April 6th, 2011 by Nick Jackson

One thing that has come out of our looking at URI structures thus far is that they tend to be heavily hierarchical, based around historical organisation attempts. This means that initially we get vaguely sensible URIs such as /mht/computing, but once we start getting down into the depths of course information it falls apart. Some things exist in multiple hierarchical ‘nodes’, making for an exciting experience when you need to decide which ‘node’ is the primary one, and should therefore have the content under it. Does a module on audio technology belong in mht/computing/audio, or mht/media/audio?

When it comes to navigating the internet this isn’t really a problem since we can link to wherever we feel like; there’s nothing inherently wrong with mht/computing and mht/media both having a link to mht/media/audio. However, this does then create a strange disconnect between computing and media – anybody who looks at the address bar is going to wonder “hang on, why am I now in the land of Media?”. Similarly on printed documentation (such as course notes) you’re going to have a load of computing students wondering why they’re being told to go to a media URI.

The problem with course-content is less apparent. Initially it looks like a lot of the content can be tidily nested, such as fees/international or accommodation/moving-in. Unfortunately it doesn’t take a lot of thought to break this model either; why should fees/international not be international/fees?

My favourite solution for this is a radical one which (in effect) totally breaks the existing model of our web content. Remove all nested content, except where there’s a clear ‘type/identifier’ model which can be followed. This leads to URIs like the following:

  • faculty/mht
  • school/computing
  • school/media
  • unit/audio
  • international-fees
  • moving-in

I’m curious to know what problems people can see with adopting this model, other than the fact that it will almost certainly require to be database/CMS backed.