Tag: tags

Tags have their uses

November 21st, 2010 — 8:59pm

Some time ago I was looking for software to support the small consultancy I worked at. It needed to include elements from groupware, customer relationship management and project management, and it needed to work over the internet. At the time we did have some complex software development going on and I was hoping there would be something that would help with that. In particular, I was looking for task hierarchies and ways of grouping and structuring associated documentation. This was at least recognised on commercial desk-top applications, but seemed thin on the ground with open source web-based software.

As it happens, I started to write my own system, but it did occur to me that the ‘tag’ feature that most of the software supported might be useful and, maybe, save me some work. This post captures some of my thoughts about tags and shows why they don’t cut it for what I want.

Tags are, primarily, a search tool. I can categorise things by anything I like, and that might include: type of document; indication of some subject covered in the document; the year or month of publication; client; and so on. So, assuming I placed the tags correctly in the first place, I can look for pages that give me specification documents that relate to a specific interface and used for a particular client. This is great. I have to maintain the tags, of course, but, given that discipline, I have a powerful search technique. What I don’t have, necessarily, is a way of looking at the context of the resulting document. I have to use some other facility in the software, or create a new search, to see pages that might relate to what I found in the first search.

What I could do, of course, is add tags that help me relate documents together, and that leads to the idea of adding, in effect, a parent to a set of documents. In other words, I can create a hierarchy by naming groups of things and placing the tags appropriately. These groups are quite flat, of course. The structure is implied and not explicit, but once I have added client, project, documentation, phase and other such things to the set of possible tags I can begin to structure the data in a useful way. This rapidly becomes difficult to maintain. A miss-spelled or forgotten tag can lead to orphaned pages that may be difficult to find (and no-one is going to bother to look if the page does not pop up in a search). Equally, the structure can be difficult to search for someone who has forgotten the exact tag.

The other thing I might be interested in doing is looking for pages that have some dynamic characteristic, such as activities that are at some particular stage in a work flow. As an example I might record system issue reports, and, after triage, they might be classified as ‘won’t fix’, ‘next software release’, and ‘showstopper’. That’s not too difficult, and is certainly flexible, because I can easily add a new status in response to the latest quality initiative. Life gets a bit more difficult if I add in another process, such as software development. Here I might have ‘next in line’, ‘in development’, ‘in testing’, and ‘released’. This also works, but I can’t prevent something going straight from ‘next in line’ to ‘released’ (I know, it happens all the time, but some people might prefer to have some control over the process.) So, it turns out that tags can be used for dynamic attributes, but, because there is no support for semantic content and it is up to the users to maintain the logical consistency of the tag set.

The unsurprising conclusion is that tags store data and can therefore be used for pretty much anything, but there is no natural semantics associated with them that allows the system to do things instead of the user. Creation of a hierarchy is a good example. In fact, the software I have written uses interwoven hierarchies and, as it turns out, the parent manifest that supports the processing is identical to a set of tags. On the other hand, when it comes to dynamic attributes, semantics is everything and the underlying storage mechanism is largely irrelevant. The ultimate conclusion, of course, is that one should design software to suit the requirements rather than trying to force a particular mechanism to do duty where it is not appropriate.

Comments Off on Tags have their uses | Development

Back to top